Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Marc G. FournierDate: 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ƂkowskiDate: 2007-10-30 16:09:01
Subject: Re: URGENT HELP about 'duration' stats

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group