Re: Proposal TODO Item: SQL-language reference parameters by name

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

In response to

Responses

Browse pgsql-hackers by date

  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