"Gevik Babakhani" <pgdev@xs4all.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:
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00294.php
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00408.php
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
checked.
regards, tom lane