Thread: Re: Allow subfield references without parentheses
Peter Eisentraut <peter@eisentraut.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
On Thu, 12 Dec 2024, 21:45 Tom Lane, <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter@eisentraut.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.
IMHO SQL standard compatibility is a more compelling argument here.