Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Apr 26, 2024 at 11:55 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Well, that would be one way of making the consistency problem be not
>> our problem, but it would be a sad restriction. It'd void a lot of
>> the arguable use-case for this feature, if you ask me. I realize
>> that non-superusers couldn't create the C-language I/O functions that
>> would be most at risk here, but you could imagine people building
>> I/O functions in some other PL.
> Huh, I hadn't considered that. I figured the performance would be too
> bad to even think about it. I also wasn't even sure such a thing would
> be supportable: I thought cstrings were generally limited to
> C/internal functions.
Performance could indeed be an issue, but I think people taking this
path would be doing so because they value programmer time more than
machine time. And while there once were good reasons to not let
user functions deal in cstrings, I'm not sure there are anymore.
(The point would deserve closer investigation if we actually tried
to move forward on it, of course.)
> Rather, what I
> don't like about the status quo is that putting parentheses around
> something that we were already going to consider as a unit changes the
> meaning of it. And that's exactly what happens when you write x.y vs.
> (x).y.
But that's exactly the point: we DON'T consider the initial identifier
of a qualified name "as a unit", and neither does the standard.
We have to figure out how many of the identifiers name an object
(column or table) referenced in the query, and that is not clear
up-front. SQL99's rules don't make that any better. The parens in
our current notation serve to separate the object name from any field
selection(s) done on the object. There's still some ambiguity,
because we allow you to write either "(table.column).field" or
"(table).column.field", but we've dealt with that for ages.
regards, tom lane