Re: BUG #5108: plpgsql function name conflict with table alias

From: Balazs Klein <balazs(dot)klein(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5108: plpgsql function name conflict with table alias
Date: 2009-10-13 07:31:45
Message-ID: 2a56a6390910130031k38dc700aja1c7c553d4b0aea9@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

I still don't know which is the bit that is syntactically not correct
> that a column name is a qualified reference to the function's OUT
parameter or
> that the function name is also a table alias
and the error message is not very helpful to find this out.

But I certainly l learned that I shouldn't do this anyway.
Thanks and regards.
Balazs

On Tue, Oct 13, 2009 at 3:04 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Balazs Klein <balazs(dot)klein(at)gmail(dot)com> writes:
> > CREATE OR REPLACE FUNCTION instreq(OUT instreq_id integer)
> > ...
> > Select instreq.instreq_id From aaa instreq
>
> The problem that you've got here is that instreq.instreq_id is in fact
> a qualified reference to the function's OUT parameter. We didn't
> support qualification of function parameter names in 8.1, but we do now.
>
> In general, I'd say that this is bad coding style. Not only do you have
> an ambiguous use of "instreq_id" (is it a column reference or a
> parameter reference?), but the name "instreq" *also* has multiple
> possible referents in this function. You'll save yourself a lot of
> headaches if you avoid that sort of thing.
>
> regards, tom lane
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Fendris 2009-10-13 09:46:18 BUG #5111: Segmentation fault, if to_tsvector returns empty row to ts_stat
Previous Message Kalev Toots 2009-10-13 05:31:44 BUG #5110: lower() function