<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>select * from depesz; &#187; plpgsql</title>
	<atom:link href="http://www.depesz.com/tag/plpgsql/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.depesz.com</link>
	<description></description>
	<lastBuildDate>Mon, 07 May 2012 20:34:27 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
		<item>
		<title>Waiting for 9.2 &#8211; NULLS from pg_*_size() functions</title>
		<link>http://www.depesz.com/2012/01/22/waiting-for-9-2-nulls-from-pg__size-functions/</link>
		<comments>http://www.depesz.com/2012/01/22/waiting-for-9-2-nulls-from-pg__size-functions/#comments</comments>
		<pubDate>Sun, 22 Jan 2012 15:51:23 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[exception]]></category>
		<category><![CDATA[pg92]]></category>
		<category><![CDATA[pg_relation_size]]></category>
		<category><![CDATA[pg_stat_user_functions]]></category>
		<category><![CDATA[pg_table_size]]></category>
		<category><![CDATA[pg_total_relation_size]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=2361</guid>
		<description><![CDATA[On 19t of January, Heikki Linnakangas committed patch: Make pg_relation_size() and friends return NULL if the object doesn't exist. &#160; That avoids errors when the functions are used in queries like &#34;SELECT pg_relation_size(oid) FROM pg_class&#34;, and a table is dropped concurrently. &#160; Phil Sorber This patch on its own is not very visible, but it [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2012/01/22/waiting-for-9-2-nulls-from-pg__size-functions/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Waiting for 9.2 &#8211; Stacked Diagnostics in PL/pgSQL</title>
		<link>http://www.depesz.com/2011/07/20/waiting-for-9-2-stacked-diagnostics-in-plpgsql/</link>
		<comments>http://www.depesz.com/2011/07/20/waiting-for-9-2-stacked-diagnostics-in-plpgsql/#comments</comments>
		<pubDate>Tue, 19 Jul 2011 23:47:45 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[context]]></category>
		<category><![CDATA[detail]]></category>
		<category><![CDATA[error]]></category>
		<category><![CDATA[exception]]></category>
		<category><![CDATA[hint]]></category>
		<category><![CDATA[pg92]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[raise]]></category>
		<category><![CDATA[stack trace]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=2262</guid>
		<description><![CDATA[On 18th of July, Tom Lane committed patch: Add GET STACKED DIAGNOSTICS plpgsql command to retrieve exception info. &#160; This is more SQL-spec-compliant, more easily extensible, and better performing than the old method of inventing special variables. &#160; Pavel Stehule, reviewed by Shigeru Hanada and David Wheeler The problem that it solves is not very [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2011/07/20/waiting-for-9-2-stacked-diagnostics-in-plpgsql/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Waiting for 9.1 &#8211; FOREACH IN ARRAY</title>
		<link>http://www.depesz.com/2011/03/07/waiting-for-9-1-foreach-in-array/</link>
		<comments>http://www.depesz.com/2011/03/07/waiting-for-9-1-foreach-in-array/#comments</comments>
		<pubDate>Mon, 07 Mar 2011 13:44:04 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[array]]></category>
		<category><![CDATA[foreach]]></category>
		<category><![CDATA[generate_subscripts]]></category>
		<category><![CDATA[pg91]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[unnest]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=2121</guid>
		<description><![CDATA[On 16th of February, Tom Lane committed patch: Add FOREACH IN ARRAY looping to plpgsql. &#160; (I'm not entirely sure that we've finished bikeshedding the syntax details, but the functionality seems OK.) &#160; Pavel Stehule, reviewed by Stephen Frost and Tom Lane This adds simpler syntax to capability that was already there, but it&#8217;s easier [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2011/03/07/waiting-for-9-1-foreach-in-array/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>How to manage changes to your database?</title>
		<link>http://www.depesz.com/2010/08/22/versioning/</link>
		<comments>http://www.depesz.com/2010/08/22/versioning/#comments</comments>
		<pubDate>Sun, 22 Aug 2010 14:39:49 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[github]]></category>
		<category><![CDATA[patch]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[versioning]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1814</guid>
		<description><![CDATA[Every now and then somebody asks how to make diff of database schemata. Usual background is like: we have production database, and development database, and we want to see what is different on development to be able to change production in the same way. Personally I think that such approach is inherently flawed. Why? First [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2010/08/22/versioning/feed/</wfw:commentRss>
		<slash:comments>24</slash:comments>
		</item>
		<item>
		<title>Test driven development for PostgreSQL</title>
		<link>http://www.depesz.com/2010/06/16/test-driven-development-for-postgresql/</link>
		<comments>http://www.depesz.com/2010/06/16/test-driven-development-for-postgresql/#comments</comments>
		<pubDate>Wed, 16 Jun 2010 11:52:51 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[pgtap]]></category>
		<category><![CDATA[plperl]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[tdd]]></category>
		<category><![CDATA[test]]></category>
		<category><![CDATA[tests]]></category>
		<category><![CDATA[trigger]]></category>
		<category><![CDATA[triggers]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1733</guid>
		<description><![CDATA[I have a mixed love/hate relationship with tests. I hate writing them. I hate remembering to add them when I&#8217;m in the zone, and application code is flowing freely from the tips of my fingers. But when I do add them, I absolutely love the ability to twist and replace the most core innards of [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2010/06/16/test-driven-development-for-postgresql/feed/</wfw:commentRss>
		<slash:comments>9</slash:comments>
		</item>
		<item>
		<title>Stupid tricks &#8211; hiding value of column in select *</title>
		<link>http://www.depesz.com/2010/04/19/stupid-tricks-hiding-value-of-column-in-select/</link>
		<comments>http://www.depesz.com/2010/04/19/stupid-tricks-hiding-value-of-column-in-select/#comments</comments>
		<pubDate>Mon, 19 Apr 2010 21:20:02 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[column]]></category>
		<category><![CDATA[columns]]></category>
		<category><![CDATA[hide]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[stupid]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1668</guid>
		<description><![CDATA[One of the most common questions is &#8220;how do I get select * from table, but without one of the column&#8221;. Short answer is of course &#8211; name your columns, instead of using *. Or use a view. But I decided to take a look at the problem. I haven&#8217;t found a way to hide [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2010/04/19/stupid-tricks-hiding-value-of-column-in-select/feed/</wfw:commentRss>
		<slash:comments>13</slash:comments>
		</item>
		<item>
		<title>Stupid tricks &#8211; Dynamic updates of fields in NEW in PL/pgSQL</title>
		<link>http://www.depesz.com/2010/03/10/dynamic-updates-of-fields-in-new-in-plpgsql/</link>
		<comments>http://www.depesz.com/2010/03/10/dynamic-updates-of-fields-in-new-in-plpgsql/#comments</comments>
		<pubDate>Tue, 09 Mar 2010 23:26:50 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[dynamic]]></category>
		<category><![CDATA[field]]></category>
		<category><![CDATA[impossible]]></category>
		<category><![CDATA[irc]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[record]]></category>
		<category><![CDATA[stupid]]></category>
		<category><![CDATA[trigger]]></category>
		<category><![CDATA[triggers]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1635</guid>
		<description><![CDATA[Dynamic updates of fields in NEW in PL/pgSQL Today, on #postgresql on IRC, strk asked about updating fields in NEW record, in plpgsql, but where name of the field is in variable. After some time, he sent his question to hackers mailing list. And he got prompt reply that it&#8217;s not possible. Well, I dare [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2010/03/10/dynamic-updates-of-fields-in-new-in-plpgsql/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Waiting for 8.5 &#8211; PL/pgSQL by default</title>
		<link>http://www.depesz.com/2010/01/07/waiting-for-8-5-plpgsql-by-default/</link>
		<comments>http://www.depesz.com/2010/01/07/waiting-for-8-5-plpgsql-by-default/#comments</comments>
		<pubDate>Thu, 07 Jan 2010 11:55:44 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[pg85]]></category>
		<category><![CDATA[pg90]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1574</guid>
		<description><![CDATA[On 18th of December Bruce Momjian committed very important, but relatively small, patch: Log Message: ----------- Install server-side language PL/pgSQL by default. There is no point in showing it, commit log tells all &#8211; basically from 8.5 on PL/pgSQL will be enabled by default in all databases. There was time when people rejected &#8220;stored procedure&#8221; [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2010/01/07/waiting-for-8-5-plpgsql-by-default/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Waiting for 8.5 &#8211; PL/pgSQL variable resolution</title>
		<link>http://www.depesz.com/2009/12/16/waiting-for-8-5-plpgsql-variable-resolution/</link>
		<comments>http://www.depesz.com/2009/12/16/waiting-for-8-5-plpgsql-variable-resolution/#comments</comments>
		<pubDate>Wed, 16 Dec 2009 13:55:17 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[incompatibility]]></category>
		<category><![CDATA[pg85]]></category>
		<category><![CDATA[pg90]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[variables]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1551</guid>
		<description><![CDATA[On 13th of November (I know, backlog again), Tom Lane committed patch which make PostgreSQL more strict about what happens in stored procedures in PL/pgSQL: Add control knobs for plpgsql's variable resolution behavior, and make the default be &#34;throw error on conflict&#34;, as per discussions. The GUC variable is plpgsql.variable_conflict, with values &#34;error&#34;, &#34;use_variable&#34;, &#34;use_column&#34;. [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2009/12/16/waiting-for-8-5-plpgsql-variable-resolution/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Waiting for 8.5 &#8211; Named function arguments</title>
		<link>http://www.depesz.com/2009/11/17/waiting-for-8-5-named-function-arguments/</link>
		<comments>http://www.depesz.com/2009/11/17/waiting-for-8-5-named-function-arguments/#comments</comments>
		<pubDate>Tue, 17 Nov 2009 00:41:51 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[functions]]></category>
		<category><![CDATA[named arguments]]></category>
		<category><![CDATA[pg85]]></category>
		<category><![CDATA[pg90]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[plpython]]></category>
		<category><![CDATA[postgresql]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1545</guid>
		<description><![CDATA[Pavel Stehule &#8211; hero for everybody writing stored procedures, wrote, and later Tom Lane committed patch which adds named arguments for functions: Log Message: ----------- Support use of function argument names to identify which actual arguments match which function parameters. The syntax uses AS, for example funcname(value AS arg1, anothervalue AS arg2) &#160; Pavel Stehule [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2009/11/17/waiting-for-8-5-named-function-arguments/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Waiting for 8.5 &#8211; DO</title>
		<link>http://www.depesz.com/2009/11/01/waiting-for-8-5-do/</link>
		<comments>http://www.depesz.com/2009/11/01/waiting-for-8-5-do/#comments</comments>
		<pubDate>Sun, 01 Nov 2009 16:09:24 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[do]]></category>
		<category><![CDATA[pg85]]></category>
		<category><![CDATA[pg90]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[sql]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1535</guid>
		<description><![CDATA[On 22nd of September, Tom Lane committed a patch by Petr Jelinek: Log Message: ----------- Implement the DO statement to support execution of PL code without having to create a function for it. &#160; Procedural languages now have an additional entry point, namely a function to execute an inline code block. This seemed a better [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2009/11/01/waiting-for-8-5-do/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Calculating backlog of events to handle</title>
		<link>http://www.depesz.com/2009/10/29/calculating-backlog-of-events-to-handle/</link>
		<comments>http://www.depesz.com/2009/10/29/calculating-backlog-of-events-to-handle/#comments</comments>
		<pubDate>Thu, 29 Oct 2009 13:37:04 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[backlog]]></category>
		<category><![CDATA[cte]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[with]]></category>
		<category><![CDATA[with recursive]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1530</guid>
		<description><![CDATA[Yesterday on my favorite IRC channel fooqux asked interesting question. I took some more questions, and here is problem description: We have a system which, every 5 minutes, takes a number of tasks to be done. Tasks are uniform. Within 5 minutes we can handle at most 100 tasks. Given the history of number of [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2009/10/29/calculating-backlog-of-events-to-handle/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Waiting for 8.5 &#8211; MOVE {FORWARD,BACKWARD} X</title>
		<link>http://www.depesz.com/2009/10/15/waiting-for-8-5-move-forwardbackward-x/</link>
		<comments>http://www.depesz.com/2009/10/15/waiting-for-8-5-move-forwardbackward-x/#comments</comments>
		<pubDate>Thu, 15 Oct 2009 11:18:25 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[cursor]]></category>
		<category><![CDATA[cursors]]></category>
		<category><![CDATA[move]]></category>
		<category><![CDATA[pg85]]></category>
		<category><![CDATA[pg90]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1513</guid>
		<description><![CDATA[On 29th of September (I know, there is a backlog &#8211; I&#8217;ll work on it, I promise), Tom Lane committed another patch from Pavel Stehule: Allow MOVE FORWARD n, MOVE BACKWARD n, MOVE FORWARD ALL, MOVE BACKWARD ALL in plpgsql. Clean up a couple of corner cases in the MOVE/FETCH syntax. &#160; Pavel Stehule Description [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2009/10/15/waiting-for-8-5-move-forwardbackward-x/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>CREATE ROLE privilege cannot be inherited?!</title>
		<link>http://www.depesz.com/2009/09/06/create-role-privilege-cannot-be-inherited/</link>
		<comments>http://www.depesz.com/2009/09/06/create-role-privilege-cannot-be-inherited/#comments</comments>
		<pubDate>Sun, 06 Sep 2009 20:07:03 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[createrole]]></category>
		<category><![CDATA[grant]]></category>
		<category><![CDATA[inheritance]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[roles]]></category>
		<category><![CDATA[workaround]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1494</guid>
		<description><![CDATA[One of my clients hit a strange limitation &#8211; apparently you cannot inherit CREATE ROLE privilege. First, let&#8217;s test if it&#8217;s really true: First, let&#8217;s create role which will have CREATE ROLE privilege: create role test1 with login createrole; Now, let&#8217;s create new role, make it inherit privileges, and grant it test1 role: # create [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2009/09/06/create-role-privilege-cannot-be-inherited/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Getting session variables without touching postgresql.conf</title>
		<link>http://www.depesz.com/2009/08/20/getting-session-variables-without-touching-postgresql-conf/</link>
		<comments>http://www.depesz.com/2009/08/20/getting-session-variables-without-touching-postgresql-conf/#comments</comments>
		<pubDate>Thu, 20 Aug 2009 18:41:26 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[configuration]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[sessions]]></category>
		<category><![CDATA[sql]]></category>
		<category><![CDATA[stackoverflow]]></category>
		<category><![CDATA[variables]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1480</guid>
		<description><![CDATA[This post has been updated with new code that uses temporary table &#8211; the code is at the end of post! There was this question on Stack Overflow. For future reference: guy asked how to do session variables &#8211; i.e. something he could define once in session, and later reuse in standard sql queries &#8211; [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2009/08/20/getting-session-variables-without-touching-postgresql-conf/feed/</wfw:commentRss>
		<slash:comments>12</slash:comments>
		</item>
		<item>
		<title>Calculating median</title>
		<link>http://www.depesz.com/2009/07/13/calculating-median/</link>
		<comments>http://www.depesz.com/2009/07/13/calculating-median/#comments</comments>
		<pubDate>Mon, 13 Jul 2009 14:13:36 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[aggregate]]></category>
		<category><![CDATA[dim]]></category>
		<category><![CDATA[irc]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[rhodiumtoad]]></category>
		<category><![CDATA[sql]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1463</guid>
		<description><![CDATA[Today, on irc (#postgresql on freenode.net) Dim mentioned about writing median calculation code. It got me thinking, and consequently writing my version of median calculation code. Before I will go any further, let me just say &#8211; after I finished, and was quite happy with what I wrote, RhodiumToad showed his approach which is (of [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2009/07/13/calculating-median/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Getting list of unique elements</title>
		<link>http://www.depesz.com/2009/07/10/getting-list-of-unique-elements/</link>
		<comments>http://www.depesz.com/2009/07/10/getting-list-of-unique-elements/#comments</comments>
		<pubDate>Fri, 10 Jul 2009 09:48:53 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[distinct]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[unique]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1455</guid>
		<description><![CDATA[Every so often you need to get list of unique elements in some column. The standard way to do it is: select distinct column from table; or select column from table group by column; The only problem is that it&#8217;s slow &#8211; as it has to seq scan whole table. Can it be done faster? [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2009/07/10/getting-list-of-unique-elements/feed/</wfw:commentRss>
		<slash:comments>11</slash:comments>
		</item>
		<item>
		<title>Getting list of all children in &#8220;adjacency list&#8221; tree structure</title>
		<link>http://www.depesz.com/2009/03/23/getting-list-of-all-children-in-adjacency-list-tree-structure/</link>
		<comments>http://www.depesz.com/2009/03/23/getting-list-of-all-children-in-adjacency-list-tree-structure/#comments</comments>
		<pubDate>Mon, 23 Mar 2009 21:08:24 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[adjacency list]]></category>
		<category><![CDATA[children]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[tree]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1396</guid>
		<description><![CDATA[So, you have a table which looks like this: # \d test Table "public.test" Column &#124; Type &#124; Modifiers -----------+---------+--------------------------------------------------- id &#124; integer &#124; not null default nextval('test_id_seq'::regclass) parent_id &#124; integer &#124; x &#124; text &#124; Indexes: "test_pkey" PRIMARY KEY, btree (id) Foreign-key constraints: "test_parent_id_fkey" FOREIGN KEY (parent_id) REFERENCES test(id) Referenced by: "test_parent_id_fkey" IN test [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2009/03/23/getting-list-of-all-children-in-adjacency-list-tree-structure/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Getting list of most common domains</title>
		<link>http://www.depesz.com/2008/12/01/getting-list-of-most-common-domains/</link>
		<comments>http://www.depesz.com/2008/12/01/getting-list-of-most-common-domains/#comments</comments>
		<pubDate>Sun, 30 Nov 2008 22:03:02 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[domain]]></category>
		<category><![CDATA[functions]]></category>
		<category><![CDATA[irc]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[report]]></category>
		<category><![CDATA[sql]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1330</guid>
		<description><![CDATA[Today, on #postgresql on IRC, guy (can&#8217;t contact him now to get his permission to name him), said: I have a table called problematic_hostnames. It contains a list of banned hostnames in column &#8220;hostname&#8221; (varchar). I would like to display the top 10 troll ISPs based on this. Does PG have a way of spotting [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2008/12/01/getting-list-of-most-common-domains/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Waiting for 8.4 &#8211; pl/* srf functions in selects</title>
		<link>http://www.depesz.com/2008/11/03/waiting-for-84-pl-srf-functions-in-selects/</link>
		<comments>http://www.depesz.com/2008/11/03/waiting-for-84-pl-srf-functions-in-selects/#comments</comments>
		<pubDate>Mon, 03 Nov 2008 12:03:01 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[functions]]></category>
		<category><![CDATA[pg84]]></category>
		<category><![CDATA[pl/*]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[select]]></category>
		<category><![CDATA[srf]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1305</guid>
		<description><![CDATA[On 28th of October Tom Lane committed his patch that changes some internals of functions, but it also adds interesting capability. Commit message: Extend ExecMakeFunctionResult() to support set-returning functions that return via a tuplestore instead of value-per-call. Refactor a few things to reduce ensuing code duplication with nodeFunctionscan.c. This represents the reasonably noncontroversial part of [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2008/11/03/waiting-for-84-pl-srf-functions-in-selects/feed/</wfw:commentRss>
		<slash:comments>6</slash:comments>
		</item>
		<item>
		<title>Removing elements from arrays</title>
		<link>http://www.depesz.com/2008/08/06/removing-elements-from-arrays/</link>
		<comments>http://www.depesz.com/2008/08/06/removing-elements-from-arrays/#comments</comments>
		<pubDate>Wed, 06 Aug 2008 18:02:42 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[arrays]]></category>
		<category><![CDATA[intarray]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[sql]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1233</guid>
		<description><![CDATA[Cezio wrote post about removing elements from arrays in PostgreSQL. Unfortunately his blog engine requires registration before comment, which I don&#8217;t like, so I decided to comment using my own blogspace. The approach Cezio showed is pretty cool &#8211; having more functions to handle arrays is definitely cool, but it might be better to use [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2008/08/06/removing-elements-from-arrays/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>Conditional DDL?</title>
		<link>http://www.depesz.com/2008/06/18/conditional-ddl/</link>
		<comments>http://www.depesz.com/2008/06/18/conditional-ddl/#comments</comments>
		<pubDate>Wed, 18 Jun 2008 12:53:23 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[conditions]]></category>
		<category><![CDATA[ddl]]></category>
		<category><![CDATA[functions]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[sql]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1217</guid>
		<description><![CDATA[Every now and then I see people ask the question &#8211; how to create table if it doesn&#8217;t exist yet, how to drop it, but only if it does exist and so on. Well, starting from 8.2 dropping should be not a problem anymore. But what about create? Alter? Let&#8217;s try to do it&#8230; First [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2008/06/18/conditional-ddl/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
		<item>
		<title>Waiting for 8.4 &#8211; CASE in pl/PgSQL</title>
		<link>http://www.depesz.com/2008/05/16/waiting-for-84-case-in-plpgsql/</link>
		<comments>http://www.depesz.com/2008/05/16/waiting-for-84-case-in-plpgsql/#comments</comments>
		<pubDate>Fri, 16 May 2008 09:54:27 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[case]]></category>
		<category><![CDATA[pg84]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1207</guid>
		<description><![CDATA[Another patch from Pavel Stehule &#8211; committed by Tom Lane. This patch adds CASE construction to pl/PgSQL: Commit log: Support SQL/PSM-compatible CASE statement in plpgsql. Pavel Stehule Of course we had CASE for a long time, but it was SQL CASE. This patch adds CASE as a statement similar to IF. There are 2 basic [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2008/05/16/waiting-for-84-case-in-plpgsql/feed/</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
		<item>
		<title>Waiting for 8.4 &#8211; pl/PgSQL RAISE</title>
		<link>http://www.depesz.com/2008/05/14/waiting-for-84-plpgsql-raise/</link>
		<comments>http://www.depesz.com/2008/05/14/waiting-for-84-plpgsql-raise/#comments</comments>
		<pubDate>Wed, 14 May 2008 16:01:20 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[pg84]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[raise]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1205</guid>
		<description><![CDATA[Today we have one new feature &#8211; extension of plpgsql&#8217;s RAISE command. Patch was written by Pavel Stehule and Tom Lane, and committed by Tom. Commit log: Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2008/05/14/waiting-for-84-plpgsql-raise/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>MySQL&#8217;s timestamp in PostgreSQL</title>
		<link>http://www.depesz.com/2008/05/08/mysqls-timestamp-in-postgresql/</link>
		<comments>http://www.depesz.com/2008/05/08/mysqls-timestamp-in-postgresql/#comments</comments>
		<pubDate>Thu, 08 May 2008 15:16:43 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[domain]]></category>
		<category><![CDATA[mysql]]></category>
		<category><![CDATA[plperl]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[timestamp]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1202</guid>
		<description><![CDATA[MySQL has this nifty/annoying feature/bug of special data type &#8220;TIMESTAMP&#8221;. It is like a DATETIME, but it gets automatically updated whenever you modify the row. I&#8217;ll try to add the same feature to PostgreSQL. This is how it works in MySQL: mysql&#62; create table test (x varchar(10), y timestamp); Query OK, 0 rows affected (0.03 [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2008/05/08/mysqls-timestamp-in-postgresql/feed/</wfw:commentRss>
		<slash:comments>6</slash:comments>
		</item>
		<item>
		<title>Waiting for 8.4 &#8211; pg_conf_load_time, time-related generate_series and enum values in \dT+</title>
		<link>http://www.depesz.com/2008/05/05/waiting-for-84-pg_conf_load_time-time-related-generate_series-and-enum-values-in-dt/</link>
		<comments>http://www.depesz.com/2008/05/05/waiting-for-84-pg_conf_load_time-time-related-generate_series-and-enum-values-in-dt/#comments</comments>
		<pubDate>Mon, 05 May 2008 07:32:38 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[generate_series]]></category>
		<category><![CDATA[pg84]]></category>
		<category><![CDATA[pg_ctl]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[psql]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1200</guid>
		<description><![CDATA[3 new functionalities from 3 people: First, patch from George Gensure, committed by Tom Lane. New function &#8211; pg_conf_load_time() returns timestamp when PostgreSQL reread its configuration last time. In trivial situation it will be the same as pg_postmaster_start_time(), but if someone issued pg_ctl reload Then it will differ: =&#62; psql -c "select pg_postmaster_start_time(), pg_conf_load_time()" pg_postmaster_start_time [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2008/05/05/waiting-for-84-pg_conf_load_time-time-related-generate_series-and-enum-values-in-dt/feed/</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
		<item>
		<title>Waiting for 8.4 &#8211; RETURN QUERY EXECUTE and cursor_tuple_fraction</title>
		<link>http://www.depesz.com/2008/05/03/waiting-for-84-return-query-execute-and-cursor_tuple_fraction/</link>
		<comments>http://www.depesz.com/2008/05/03/waiting-for-84-return-query-execute-and-cursor_tuple_fraction/#comments</comments>
		<pubDate>Sat, 03 May 2008 12:52:19 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[guc]]></category>
		<category><![CDATA[pg84]]></category>
		<category><![CDATA[planner]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1199</guid>
		<description><![CDATA[Today another two new additions to PostgreSQL &#8211; as You can see may commit-fest seems to work pretty good First change is new functionality in pl/pgsql: RETURN QUERY EXECUTE. Pavel Stehule, and Tom Lane committed patch which lets You use new command, or to be more specific extend existing command. &#8220;RETURN QUERY&#8221; was added in [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2008/05/03/waiting-for-84-return-query-execute-and-cursor_tuple_fraction/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>My take on trees in SQL</title>
		<link>http://www.depesz.com/2008/04/11/my-take-on-trees-in-sql/</link>
		<comments>http://www.depesz.com/2008/04/11/my-take-on-trees-in-sql/#comments</comments>
		<pubDate>Fri, 11 Apr 2008 15:45:21 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>
		<category><![CDATA[tree]]></category>
		<category><![CDATA[trigger]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1192</guid>
		<description><![CDATA[Quick note in polish: jeśli znasz moje poprzednie posty nt. drzew, to ten możesz sobie pewnie odpuścić. będzie zawierał jedynie opis implementacji zbliżony do tego co już jest dostępne. OK, back to English (or at least my version of English). Finding a good way to store trees in SQL was/is my long-term hobby. I tried [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2008/04/11/my-take-on-trees-in-sql/feed/</wfw:commentRss>
		<slash:comments>25</slash:comments>
		</item>
		<item>
		<title>waiting for 8.4 &#8211; current_query()</title>
		<link>http://www.depesz.com/2008/04/05/waiting-for-84-current_query/</link>
		<comments>http://www.depesz.com/2008/04/05/waiting-for-84-current_query/#comments</comments>
		<pubDate>Sat, 05 Apr 2008 10:42:02 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[current_query]]></category>
		<category><![CDATA[databases]]></category>
		<category><![CDATA[pg84]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1190</guid>
		<description><![CDATA[unfrotunatelly i can&#8217;t point you to message in archives, as there is some problem with them, and i dont see posts newer than &#8220;Fri Apr 04 12:00:08 2008&#8243;. this patch was written by tomas doran, and commited by bruce momjian: Log Message: ----------- Implement current_query(), that shows the currently executing query. At the same time [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2008/04/05/waiting-for-84-current_query/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
		<item>
		<title>waiting for 8.4</title>
		<link>http://www.depesz.com/2008/04/02/waiting-for-84-3/</link>
		<comments>http://www.depesz.com/2008/04/02/waiting-for-84-3/#comments</comments>
		<pubDate>Wed, 02 Apr 2008 12:51:51 +0000</pubDate>
		<dc:creator>depesz</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[databases]]></category>
		<category><![CDATA[execute]]></category>
		<category><![CDATA[pg84]]></category>
		<category><![CDATA[plpgsql]]></category>
		<category><![CDATA[postgresql]]></category>

		<guid isPermaLink="false">http://www.depesz.com/?p=1189</guid>
		<description><![CDATA[another very interesting addon. pavel stehule wrote, and tom lane commited &#8220;execute using&#8221; in plpgsql. if you ever wrote in plpgsql you know that in some cases you had to use execute 'insert into ... usually it was neccessary when you wanted dynamic table or column names or you were writing code like this: select [...]]]></description>
		<wfw:commentRss>http://www.depesz.com/2008/04/02/waiting-for-84-3/feed/</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
	</channel>
</rss>

