Re: Controlling changes in plpgsql variable resolution

"Eric B. Ridge" <ebr(at)tcdi(dot)com> writes:
> On Oct 19, 2009, at 2:47 PM, Tom Lane wrote:
>> 1. Invent a GUC that has the settings backwards-compatible,
>> oracle-compatible, throw-error (exact spellings TBD). Factory
>> default,
>> at least for a few releases, will be throw-error.

> Sorry if this is obvious to everyone else, but *when* will the error
> throw?

Whenever we do semantic analysis of the particular query or expression.

> During CREATE FUNCTION or during runtime? I'm secretly hoping
> that it'll throw during CREATE FUNCTION.

Be careful what you ask for, you might get it ;-)

The problem with doing more than minimal syntax checking during CREATE
FUNCTION, or even at the start of function execution, is that people
are far too accustomed to being able to do things like

CREATE TEMP TABLE foo ( ... );
INSERT INTO foo ... ;

and of course the second command will fail outright if foo doesn't exist
--- or even if we made that not fail, how will we do any meaningful
semantic checking of later SELECTs against foo? Another example is a
fairly common pattern in trigger functions:

if tg_op = 'insert' then
... do something with new.* ...
else if tg_op = 'delete' then
... do something with old.* ...
... etc ...

where semantic checking on the non-executed parts of the function would
certainly throw error.

I would love to offer an option that "fully" checks plpgsql functions
but I think it would break so much code that no one could really use it.

In any case this is pretty much unrelated to the current patch...

regards, tom lane