Обсуждение: Reserved words and named function parameters

I've been reviewing Dennis Bjorklund's patch to support named
function parameters:
http://archives.postgresql.org/pgsql-patches/2003-12/msg00176.php

One thing I didn't like about it was that the grammar declared
param_name as plain IDENT, meaning that you could not use even
"unreserved" keywords as param names.  One would prefer ColId, but
naturally that causes a truckload of shift and reduce conflicts :-(

After some fooling around I find that these combinations work:

1. Make param_name equate to type_name (allowing IDENT or
unreserved_keyword), and move the following keywords from
"unreserved" to "col_name_keyword" status:DOUBLE INOUT NATIONAL OUT

2. Make param_name equate to function_name (allowing IDENT,
unreserved_keyword, or func_name_keyword).  This requires the
above changes plus moving "IN" from func_name_keyword to fully
reserved status.

Any opinions which to do, or alternate proposals?  I'm leaning
slightly to #2, since I doubt anyone is trying to use "IN" as
a function name, but ...
        regards, tom lane

Tom Lane wrote:

>I've been reviewing Dennis Bjorklund's patch to support named
>function parameters:
>http://archives.postgresql.org/pgsql-patches/2003-12/msg00176.php
>
>One thing I didn't like about it was that the grammar declared
>param_name as plain IDENT, meaning that you could not use even
>"unreserved" keywords as param names.  One would prefer ColId, but
>naturally that causes a truckload of shift and reduce conflicts :-(
>
>After some fooling around I find that these combinations work:
>
>1. Make param_name equate to type_name (allowing IDENT or
>unreserved_keyword), and move the following keywords from
>"unreserved" to "col_name_keyword" status:
>    DOUBLE INOUT NATIONAL OUT
>
>2. Make param_name equate to function_name (allowing IDENT,
>unreserved_keyword, or func_name_keyword).  This requires the
>above changes plus moving "IN" from func_name_keyword to fully
>reserved status.
>
>Any opinions which to do, or alternate proposals?  I'm leaning
>slightly to #2, since I doubt anyone is trying to use "IN" as
>a function name, but ...
>
>  
>

I support #2 rather more strongly ;-)

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> 1. Make param_name equate to type_name (allowing IDENT or
>> unreserved_keyword), and move the following keywords from
>> "unreserved" to "col_name_keyword" status:
>> DOUBLE INOUT NATIONAL OUT
>> 
>> 2. Make param_name equate to function_name (allowing IDENT,
>> unreserved_keyword, or func_name_keyword).  This requires the
>> above changes plus moving "IN" from func_name_keyword to fully
>> reserved status.
>> 
>> Any opinions which to do, or alternate proposals?  I'm leaning
>> slightly to #2, since I doubt anyone is trying to use "IN" as
>> a function name, but ...

> I support #2 rather more strongly ;-)

After further fooling about, I think it might be better to transfer
PRECISION instead of DOUBLE to the col_name_keyword category.  The
reason we need to do one or the other iscreate function foo(double precision) ...
If both words are unreserved then there are two possible parses ---
either "double precision" as a type spec, or "double" as a parameter
name and "precision" as a type name.

The reason for not wanting to make "double" even a little bit reserved
is that this regression test fails with a syntax error:

CREATE TYPE widget (  internallength = 24,   input = widget_in,  output = widget_out,  alignment = double
);

We could require people to start quoting "double" in this context, but
I think the path of least resistance is probably to make "precision"
a little bit reserved, instead.  Anyone have a strong attachment to
custom datatypes named either?
        regards, tom lane

> Any opinions which to do, or alternate proposals?  I'm leaning
> slightly to #2, since I doubt anyone is trying to use "IN" as
> a function name, but ...

One addition.  The information_schema.parameters view will need to be 
updated to reflect parameter names.

http://www.postgresql.org/docs/7.4/static/infoschema-parameters.html

Quote: "Always null, since PostgreSQL does not support named parameters"

Chris