Re: Specific names for plpgsql variable-resolution control options?

From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Specific names for plpgsql variable-resolution control options?
Date: 2009-11-06 21:57:10
Message-ID: 06651A03-B151-4904-A8E8-1BEB2B11D548@kineticode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Nov 6, 2009, at 12:21 PM, Tom Lane wrote:

> 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?

plpgsql_variable_conflict = fatal | oracle-compat | pg-compat

?

Best,

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-11-06 22:01:55 Re: Specific names for plpgsql variable-resolution control options?
Previous Message Tom Lane 2009-11-06 20:21:30 Specific names for plpgsql variable-resolution control options?