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

From Robert Haas
Subject Re: Controlling changes in plpgsql variable resolution
Date
Msg-id 603c8f070910190836t6c443d90s252a7e34d9f7904e@mail.gmail.com
Whole thread Raw
In response to Re: Controlling changes in plpgsql variable resolution  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Controlling changes in plpgsql variable resolution
List pgsql-hackers
On Mon, Oct 19, 2009 at 10:54 AM, Stephen Frost <sfrost@snowman.net> wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> I think there are basically three behaviors that we could offer:
>>
>> 1. Resolve ambiguous names as plpgsql (historical PG behavior)
>> 2. Resolve ambiguous names as query column (Oracle behavior)
>> 3. Throw error if name is ambiguous (useful for finding problems)
>
> 4. Resolve ambiguous names as query column, but throw warning
>
> #4 would be my vote, followed by #3.  To be perfectly honest, I'd be a
> whole lot happier with a pl/pgsql that let me prefix variable names with
> a '$' or similar to get away from this whole nonsense.  I've been very
> tempted to tell everyone I work with to start prefixing their variables
> names with '_' except that it ends up looking just plain ugly.

I think warnings are too easy to miss, but I agree your other
suggestion.  I know you can write function_name.variable_name, but
that's often massively long-winded.  We either need a short, fixed
prefix, or some kind of sigil.  I previously suggested ? to parallel
ECPG, but Tom didn't like it.  I still do.  :-)

...Robert


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: COPY enhancements
Next
From: Robert Haas
Date:
Subject: Re: Application name patch - v2