Thread: 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