Andrew Dunstan <[EMAIL PROTECTED]> 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 is create 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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings