Re: Specific names for plpgsql variable-resolution control options? - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Specific names for plpgsql variable-resolution control options?
Date
Msg-id 162867790911062323m59684214nc15dee0d3b98c83@mail.gmail.com
Whole thread Raw
In response to Specific names for plpgsql variable-resolution control options?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
2009/11/6 Tom Lane <tgl@sss.pgh.pa.us>:
> I believe we had consensus that plpgsql should offer the following three
> behaviors when a name in a SQL query could refer to either a plpgsql
> variable or a column from a table of the query:
>        * prefer the plpgsql variable (plpgsql's historical behavior)
>        * prefer the table column (Oracle-compatible)
>        * throw error for the ambiguity (to become the factory default)
> and that we wanted a way for users to select one of these behaviors at the
> per-function level, plus provide a SUSET GUC to determine the default
> behavior when there is not a specification in the function text.
>
> What we did not have was any concrete suggestions for the name or
> values of the GUC, nor for the exact per-function syntax beyond the
> thought that it could look something like the existing '#option dump'
> modifier.
>
> The code is now there and ready to go, so I need a decision on these
> user-visible names in order to proceed.  Anyone have ideas?

embeded_sql_identif_priority = sql|embeded|exception

regards
Pavel Stehule

>
>                        regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Why do OLD and NEW have special internal names?
Next
From: Heikki Linnakangas
Date:
Subject: Getting consistent snapshot in multiple backends, for parallel pg_dump