Marco Nenciarini <marco.nenciar...@2ndquadrant.it> writes:
> Please find the attached refreshed patch (v2) which fixes the loose ends
> you found.
I've started looking at this patch, and the first thing I notice is that
the syntax doesn't work. It's ambiguous, and this:
%left JOIN CROSS LEFT FULL RIGHT INNER_P NATURAL
/* kluge to keep xml_whitespace_option from causing shift/reduce conflicts */
%right PRESERVE STRIP_P
+ %nonassoc ELEMENT
%%
is not in any way an acceptable fix. All that that will do is cause an
arbitrary choice to be made when it's not clear what to do. Half the
time the arbitrary choice will be wrong. Consider for example
regression=# create table t1 (f1 int[] default 4! element references t2);
ERROR: column "element" does not exist
The parser has resolved the ambiguity about whether "!" is an infix or
postfix operator by assuming it's infix. (Yeah, I realize we've "fixed"
some similar cases with precedence hacks, but they are cases that were
forced on us by brain-dead syntax choices in the SQL standard. We don't
need to go there for syntax we're making up ourselves.)
We could get around that by making ELEMENT a fully reserved word, but
I don't think that's a really acceptable solution. ELEMENT is reserved
according to more recent versions of the SQL standard, but only as a
built-in function name, and in any case reserving it is very likely to
break people's existing applications.
Another possibility is to forget about the column constraint ELEMENT
REFERENCES syntax, and only support the table-constraint syntax with
ELEMENT inside the column list --- I've not checked, but I think that
syntax doesn't have any ambiguity problems.
Or we could go back to using ARRAY here --- that should be safe since
ARRAY is already fully reserved.
Or we could choose some other syntax. I'm wondering about dropping the
use of a keyword entirely, and instead using '[]' decoration. This
wouldn't work too badly in the table constraint case:
FOREIGN KEY (foo, bar[]) REFERENCES t (x,y)
but I'm less sure where to put the decoration for the column constraint
case.
Thoughts?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
