Re: Fast default stuff versus pg_upgrade

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Fast default stuff versus pg_upgrade
Дата
Msg-id 19514.1529601502@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Fast default stuff versus pg_upgrade  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Ответы Re: Fast default stuff versus pg_upgrade  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Список pgsql-hackers
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 06/21/2018 12:39 PM, Tom Lane wrote:
>> Andres Freund <andres@anarazel.de> writes:
> On June 21, 2018 9:04:28 AM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> This isn't really ready to go.  One clear problem is that you broke
> pg_dump'ing from any pre-v11 version, because you did not add suitable
> null outputs to the pre-v11 query variants in getTableAttrs.

> I followed the pattern used for attidentity. But why will it spit out 
> warnings? It doesn't ask for the missing stuff from an older version.

Oh, I see.  Well, the short answer is that that's not the style we use
in pg_dump, and the attidentity code is inappropriate/wrong too IMO.
When something has been done one way a hundred times before, thinking
you're too smart for that and you'll do it some other way does not lend
itself to code clarity or reviewability.

I might be OK with a patch that converts *all* of pg_dump's cross-version
difference handling code to depend on PQfnumber silently returning -1
rather than failing, but I don't want to see it done like that in just
one or two places.

            regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robbie Harwood
Дата:
Сообщение: Re: libpq compression
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Fast default stuff versus pg_upgrade