"Gevik Babakhani" <pgdev(at)xs4all(dot)nl> writes:
> Implementation of the name parameter parsing in scan.l/gram.y can be
> achieved by adopting the same mechanism as plpgsql does.
If you do that it will likely be rejected outright, because there's
considerable agreement that plpgsql is wrong/broken on this point.
Check the archives, eg these two threads:
Parameter and variable names really need to be in an outer scope
such that they bind less tightly than names available within a SQL
query. I'm not sure if we'll ever risk breaking existing applications
by switching around the priority in plpgsql functions, but that's
not a reason not to get it right in sql functions.
I think the most likely implementation would involve adding hooks
in the parser at places where "unknown column" errors are about to
be thrown, so that a function language could check for a match to
one of its variable names only after the query-exposed names are
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Marc G. Fournier||Date: 2007-10-30 16:35:21|
|Subject: Re: [COMMITTERS] pgsql: simple script to pull together a very small
(<500k) tar file|
|Previous:||From: Filip Rembiałkowski||Date: 2007-10-30 16:09:01|
|Subject: Re: URGENT HELP about 'duration' stats|