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
|
| Список | 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 по дате отправления: