From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Allow subfield references without parentheses |
Date: | 2024-12-12 16:45:01 |
Message-ID: | 658534.1734021901@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> This patch allows subfield references in column references without
> parentheses, subject to certain condition. This implements (hopes to,
> anyway) the rules from the SQL standard (since SQL99).
> This has been requested a number of times over the years. [0] is a
> recent discussion that has mentioned it.
The obvious concern about this is introduction of ambiguity where
there was none before.
> If both possible interpretations apply, then an error is raised. (A
> workaround is to change the alias used in the query.) Such errors
> should be very rare in practice.
Not sure if it's rare or not, but I agree with raising an error rather
than silently choosing one alternative. We won't find out if it's
problematic unless we throw an error.
> ... I also studied ruleutils.c a
> bit to see if there are any tweaks needed to support this. So far it
> seems okay. I'm sure we can come up with some pathological cases, but
> so far I haven't done anything about it.
I assume that what will happen is that ruleutils will continue to emit
our traditional notation with the extra parentheses. I think we need
to leave it like that, so as not to create a compatibility booby-trap
for loading dumps into older PG versions.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-12-12 16:51:37 | Re: Controlling the usage of a user-defined cast |
Previous Message | Jacob Champion | 2024-12-12 16:44:33 | Re: SCRAM pass-through authentication for postgres_fdw |