On Thu, 25 Apr 2024 at 17:05, Tom Lane <t...@sss.pgh.pa.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.
