Re: Controlling changes in plpgsql variable resolution - Mailing list pgsql-hackers

From Eric B. Ridge
Subject Re: Controlling changes in plpgsql variable resolution
Date
Msg-id 594AC745-9A4B-49AD-BAC0-2FEA1C468B7D@tcdi.com
Whole thread Raw
In response to Re: Controlling changes in plpgsql variable resolution  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Oct 19, 2009, at 3:46 PM, Tom Lane wrote:

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

That's what I figured.

>> 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 ;-)

<snip really good reasons>

Yeah, and we've got at least one function that does the CREATE TEMP  
TABLE foo (...) pattern.  So I understand.

We want to our schema to keep pace with whatever the default settings  
are for stuff like this, so it'd be great if we could find and resolve  
the issues sooner rather than later.  We implemented better coding  
practices later on in the project to help us disambiguate between  
variables and columns, but there's still a bunch of legacy stuff  
that's going to be broken.

eric


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: LATERAL
Next
From: Ron Mayer
Date:
Subject: Could postgres be much cleaner if a future release skipped backward compatibility?