"Gevik Babakhani" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
