Re: Fast default stuff versus pg_upgrade

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Fast default stuff versus pg_upgrade
Дата
Msg-id 15540.1529597068@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Fast default stuff versus pg_upgrade  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Ответы Re: Fast default stuff versus pg_upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Fast default stuff versus pg_upgrade  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> Patch after pgindent attached. This will involve a catversion bump since 
> we're adding a new function.

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.

Personally, I'd have made the pg_dump changes simpler and cheaper by
storing only one new value per column not two.  You could have just
stored attmissingval, or if you want to be paranoid you could do

    case when atthasmissing then attmissingval else null end

We could do without the unrelated whitespace changes in dumpDefaultACL,
too (or did pgindent introduce those?  Seems surprising ... oh, looks
like "type" has somehow snuck into typedefs.list.  Time for another
blacklist entry.)

In dumpTableSchema, I'd suggest emitting the numeric table OID, rather
than hacking around with regclass.

            regards, tom lane


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

Предыдущее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: libpq compression
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Fast default stuff versus pg_upgrade