Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Rod TaylorDate: 2005-10-28 18:57:03
Subject: Re: enums
Previous:From: Jim C. NasbyDate: 2005-10-28 18:23:27
Subject: Re: enums

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group