Re: pl/pgsql breakage in 8.1b4?

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

In response to

Browse pgsql-hackers by date

  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