From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Philip Yarra <philip(at)utiba(dot)com>, Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pl/pgsql breakage in 8.1b4? |
Date: | 2005-10-28 18:30:51 |
Message-ID: | 20051028183050.GL13187@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Oct 28, 2005 at 12:10:00AM -0400, Tom Lane wrote:
> Philip Yarra <philip(at)utiba(dot)com> writes:
> > Without really wishing to volunteer myself: should plpgsql allow using
> > parameters with the same name as the columns being referred to within the
> > function, provided they're qualified as function_name.parameter?
>
> No, because that just changes where the ambiguity is. The function name
> could easily conflict with a table name. It's a mighty weird-looking
> convention anyway --- on what grounds would you argue that the function
> is a structure having parameter names as fields?
Is there some other means we could come up with to distinguish between
field names and variables? Maybe local.variablename?
Oracle has similar issues where you have to use
functionname.variablename if there's a conflict, which is a pita. Hence
the standard advice of always prefixing your variables with something,
but that seems like an ugly hack to me. Of course the real issue is the
namespace conflict to begin with, but I have no idea how to solve that..
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2005-10-28 18:57:03 | Re: enums |
Previous Message | Jim C. Nasby | 2005-10-28 18:23:27 | Re: enums |