Re: Why don't we support external input/output functions for the composite types

On Thu, 25 Apr 2024 at 17:05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> > I think it's confusing and counterintuitive that putting parentheses
> > around a subexpression completely changes the meaning. I don't know of
> > any other programming language that behaves that way,
>
> I take it that you also don't believe that "2 + 3 * 4" should yield
> different results from "(2 + 3) * 4"?
>

In that expression "2 + 3" is not a subexpression, although "3 * 4"
is, thanks to the operator precedence rules.

I could get behind offering an alternative notation, eg "a.b->c does
> the same thing as (a.b).c", if we could find a reasonable notation
> that doesn't infringe on user operator namespace. I think that might
> be hard to do though, and I don't think the existing notation is so
> awful than we should break existing operators to have an alternative.
> The business with deprecating => operators a few years ago had the
> excuse that "the standard says so", but we don't have that
> justification here.
>

This is one of those areas where it will be difficult at best to do
something which makes things work the way people expect without breaking
other cases. I certainly would like to be able to use . to extract a field
from a composite value without parenthesizing everything, but given the
potential for having a schema name that matches a table or field name I
would want to be very careful about changing anything.