Re: Improving inferred query column names

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Improving inferred query column names
Дата
Msg-id CAKFQuwb0=AVyE=rnEVTa7hthKh+EPL_ufdcDZ40vucB+bij1RA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Improving inferred query column names  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: Improving inferred query column names  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: pg_init_privs corruption.
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: ExecRTCheckPerms() and many prunable partitions (checkAsUser)