From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Gevik Babakhani" <pgdev(at)xs4all(dot)nl> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal TODO Item: SQL-language reference parameters by name |
Date: | 2007-10-30 16:35:09 |
Message-ID: | 24256.1193762109@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"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:
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
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2007-10-30 16:35:21 | Re: [COMMITTERS] pgsql: simple script to pull together a very small (<500k) tar file |
Previous Message | Filip Rembiałkowski | 2007-10-30 16:09:01 | Re: URGENT HELP about 'duration' stats |