Re: [REVIEW] Re: Re: BUG #9578: Undocumented behaviour for temp tables created inside query language (SQL) functions

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>
Cc: David Johnston <polobo(at)yahoo(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [REVIEW] Re: Re: BUG #9578: Undocumented behaviour for temp tables created inside query language (SQL) functions
Date: 2014-06-18 07:57:24
Message-ID: CAJrrPGdgsQtriPt=oGvohLcD6+Mf9JOdDbt7Tj2sMjqV-0LMww@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Tue, Jun 17, 2014 at 12:30 AM, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com> wrote:
> (Cc: to pgsql-bugs dropped.)
>
> At 2014-03-17 18:24:55 +1100, kommi(dot)haribabu(at)gmail(dot)com wrote:
>>
>> *** a/doc/src/sgml/xfunc.sgml
>> --- b/doc/src/sgml/xfunc.sgml
>> ***************
>> *** 153,159 **** SELECT clean_emp();
>> --- 153,186 ----
>> (<literal>\</>) (assuming escape string syntax) in the body of
>> the function (see <xref linkend="sql-syntax-strings">).
>> </para>
>> +
>> + <sect2 id="xfunc-sql-function-parsing-mechanism">
>> + <title>Parsing mechanism of a function</title>
>>
>> + <indexterm>
>> + <primary>function</primary>
>> + <secondary>parsing mechanism</secondary>
>> + </indexterm>
>
> I suggest "Catalog changes within functions" instead of the above title.
>
>> + <para>
>> + The body of an SQL function is parsed as if it were a single - multi-part
>> + statement and thus uses a constant snapshot of the system catalogs for
>> + every sub-statement therein. Commands that alter the catalog will likely not
>> + work as expected.
>> + </para>
>> +
>> + <para>
>> + For example: Issuing "CREATE TEMP TABLE" within an SQL function will add
>> + the table to the catalog but subsequent statements in the same function will
>> + not see those additions and thus the temporary table will be invisible to them.
>> + </para>
>> +
>> + <para>
>> + Thus it is generally advised that <application>PL/pgSQL</> be used, instead of
>> + <acronym>SQL</acronym>, when any catalog visibilities are required in the same function.
>> + </para>
>> + </sect2>
>
> I don't think that much text is warranted. I suggest something like the
> following condensed wording:
>
> <para>
> The body of an SQL function is parsed as if it were a single
> multi-part statement, using a constant snapshot of the system
> catalogs. The effect of any commands that alter the catalogs
> (e.g. "CREATE TEMP TABLE") will therefore not be visible to
> subsequent commands in the function body.
> </para>
>
> <para>
> The recommended workaround is to use <application>PL/PgSQL</>.
> </para>
>
> Does that seem sensible to you?

Looks good, Thanks for the review.
Updated patch attached.

Regards,
Hari Babu
Fujitsu Australia

Attachment Content-Type Size
sql_functions_parsing_doc_v2.patch application/octet-stream 1.1 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Abhijit Menon-Sen 2014-06-18 09:50:34 Re: Re: [REVIEW] Re: Re: BUG #9578: Undocumented behaviour for temp tables created inside query language (SQL) functions
Previous Message Pavan Deolasee 2014-06-18 07:01:59 Re: BUG #10675: alter database set tablespace and unlogged table

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2014-06-18 08:06:29 Re: include_dir catch-22
Previous Message Craig Ringer 2014-06-18 07:30:06 include_dir catch-22