Ühel kenal päeval, T, 2007-10-30 kell 09:35, kirjutas David Fetter:
On Tue, Oct 30, 2007 at 02:31:52PM +0100, Gevik Babakhani wrote:
Hi all,
I am working a lot with custom procedures/functions which are
implemented in language sql. At the moment function parameter refs
cannot work
Lane [EMAIL PROTECTED]
To: Gevik Babakhani [EMAIL PROTECTED]
Cc: pgsql-hackers@postgresql.org
Sent: Wednesday, October 31, 2007 4:36 AM
Subject: Re: [HACKERS] Proposal TODO Item: SQL-language reference parameters
by name
Gevik Babakhani [EMAIL PROTECTED] writes:
I think the most likely
Hi all,
I am working a lot with custom procedures/functions which are implemented in
language sql. At the moment function parameter refs cannot work with
parameter names. I would like to try to implement this. The actual TODO item is:
Allow SQL-language functions to reference parameters
On Tue, Oct 30, 2007 at 02:31:52PM +0100, Gevik Babakhani wrote:
Hi all,
I am working a lot with custom procedures/functions which are
implemented in language sql. At the moment function parameter refs
cannot work with parameter names. I would like to try to implement
this. The actual TODO
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
Thank you Tom.
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.
Would
Gevik Babakhani [EMAIL PROTECTED] writes:
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
