Re: Fast default stuff versus pg_upgrade

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Fast default stuff versus pg_upgrade
Дата
Msg-id 25330.1529425076@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Fast default stuff versus pg_upgrade  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: Fast default stuff versus pg_upgrade  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> I have no idea how large an actual fix might be. I'll at least start 
> working on it immediately. I agree it's very late in the day.

On reflection, it seems like there are two moving parts needed:

* Add a binary-upgrade support function to the backend, which would take,
say, table oid, column name, and some representation of the default value;

* Teach pg_dump when operating in binary-upgrade mode to emit a call to
such a function for each column that has atthasmissing true.

The hard part here is how exactly are we going to represent the default
value.  AFAICS, the only thing that pg_dump could readily lay its hands
on is the "anyarray" textual representation of attmissingval, which maybe
is okay but it means more work for the support function.  Too bad we did
not just store the value in bytea format.

            regards, tom lane


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

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