Thread: Re: Allow subfield references without parentheses

Re: Allow subfield references without parentheses

From
Tom Lane
Date:
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



Re: Allow subfield references without parentheses

From
Kirill Reshke
Date:


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.