Re: Improving inferred query column names - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Improving inferred query column names
Date
Msg-id CAKFQuwb0=AVyE=rnEVTa7hthKh+EPL_ufdcDZ40vucB+bij1RA@mail.gmail.com
Whole thread Raw
In response to Re: Improving inferred query column names  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: Improving inferred query column names
List pgsql-hackers
On Mon, Feb 20, 2023 at 8:08 AM Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:
On 11.02.23 20:24, Andres Freund wrote:
>
> I think on a green field it'd be clearly better to do something like the
> above.  What does give me pause is that it seems quite likely to break
> existing queries, and to a lesser degree, might break applications relying on
> inferred column names
>
> Can anybody think of a good way out of that? It's not like that problem is
> going to go away at some point...

I think we should just do it and not care about what breaks.  There has
never been any guarantee about these.


I'm going to toss a -1 into the ring but if this does go through a strong request that it be disabled via a GUC.  The ugliness of that option is why we shouldn't do this.

Defacto reality is still a reality we are on the hook for.

I too find the legacy design choice to be annoying but not so much that changing it seems like a good idea.

David J.

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: pg_init_privs corruption.
Next
From: Alvaro Herrera
Date:
Subject: Re: ExecRTCheckPerms() and many prunable partitions (checkAsUser)