Re: Controlling changes in plpgsql variable resolution

From: "Eric B(dot) Ridge" <ebr(at)tcdi(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Controlling changes in plpgsql variable resolution
Date: 2009-10-19 21:01:07
Message-ID: 594AC745-9A4B-49AD-BAC0-2FEA1C468B7D@tcdi.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message marcin mank 2009-10-19 21:08:40 per table random-page-cost?
Previous Message Greg Stark 2009-10-19 20:39:44 Re: LATERAL