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

On Thu, Apr 25, 2024 at 5:51 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> A different approach we could take is to implement the SQL99 rules
> for <identifier chain>, or at least move closer to that. Our
> existing rules for resolving qualified column references are more
> or less SQL92. I think the reasons we didn't do that when we first
> implemented SQL99 are

I'm not familiar with these rules. Do they allow stuff like a.b.c.d.e,
or better yet, a.b(args).c(args).d(args).e(args)?

> Still, maybe it's time to think about changing? We could use
> the "the standard says so" excuse with anybody who complains.

I certainly agree that if we're going to break stuff, breaking stuff
to get closer to the standard is superior to other ways of breaking
stuff. Without knowing what we'd get out of it, I don't have an
opinion about whether it's worth it here or not, but making our syntax
more like other programming languages and especially other popular
database products does seem to me to have positive value.

> In the long run I wish we could ditch the SQL92 rules altogether
> and say that the head identifier of a qualified column reference
> must be a table's correlation name, not a schema or catalog name.
> There's zero good reason for the latter two cases, other than
> compatibility with thirty-year-old design mistakes. I kind of
> doubt we could make that fly though.

Yeah, I think that would break too much stuff.

--
Robert Haas
EDB: http://www.enterprisedb.com