So where do we go from here?

a. <function name>.<arg name>
b. <this>.<arg name>
c. ':'<argname>
d. just <argname>

option a,b and d are easy to implement.
option d would be least clear and readable considering
sql functions can be long and have multiple arguments.
option c is more difficult because gram.y has to be modified 
to understand ':'<identifier> as parameter but not a target_list item.

option a and b would make the source more readable
but extra documentation has to be provided to describe 
how to refer arguments by name.


Gevik Babakhani

PostgreSQL NL
TrueSoftware BV

> -----Original Message-----
> [mailto:[EMAIL PROTECTED] On Behalf Of Gregory Stark
> Sent: Saturday, November 03, 2007 6:22 PM
> To: David Fetter
> Cc: Tom Lane; Gevik Babakhani;
> Subject: Re: [PATCHES] V0.2 patch for TODO Item: SQL-language 
> referenceparameters by name.
> "David Fetter" <[EMAIL PROTECTED]> writes:
> > What I mean by "kinda" is that it's a standard way of handling 
> > parameters in Oracle and in DBI.
> That's a good reason *not* to use them for other purposes. 
> Users trying to create procedures through DBI or other 
> interfaces like it will run into problems when the driver 
> misinterprets the parameters.
> > I think it would be a very bad idea
> > to require that people use the function name in parameters,
> I think were talking about only allowing it to disambiguate 
> if the name is shadowed by a variable in an inner scope.
> --
>   Gregory Stark
>   EnterpriseDB
>   Ask me about EnterpriseDB's RemoteDBA services!
> ---------------------------(end of 
> broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to [EMAIL PROTECTED] 
> so that your
>        message can get through to the mailing list cleanly

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to