Re: magical eref alias names - Mailing list pgsql-hackers

From Robert Haas
Subject Re: magical eref alias names
Date
Msg-id CA+TgmoZJLbnAmvsUpSBXh=pYYuS+knG7zK18znwb7A+abgKh9g@mail.gmail.com
Whole thread Raw
In response to Re: magical eref alias names  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: magical eref alias names
List pgsql-hackers
On Thu, Nov 7, 2024 at 4:07 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Is there some strong reason to insist on making that core-dump-risking
> change, rather than simply assigning the now-one-size-fits-all alias
> when creating Alias nodes?

What I'm unhappy about is not being able to tell the difference
between a name that was invented by or at least meaningful to the user
and one that isn't. Filling in unnamed_subquery everywhere doesn't
accomplish that because the user could in theory supply that name;
even if that were no issue, I do not want to have code like:

if (strcmp(aliasname, "unnamed_subquery") == 0 || (strncmp(aliasname,
"unnamed_subquery_", strlen("unnamed_subquery_") && something
complicated with strtol to see if the rest of the name is an integer))
   ... looks system generated ...
else
   ... looks user generated ...

I would be more sympathetic to the idea of system-generated aliases if
they were generated in a way that made it likely that they would be
meaningful to the user. In fact, if they were generated in such a way
that they would be unique, that would actually be fantastic and I
would definitely not be arguing for removing them. But I think what we
have right now is a mess.

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: magical eref alias names
Next
From: "Devulapalli, Raghuveer"
Date:
Subject: RE: Use __attribute__((target(sse4.2))) for SSE42 CRC32C