Re: Fast default stuff versus pg_upgrade

On 2018-06-19 12:17:56 -0400, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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.

Isn't that just a few lines of code? And if the default value bugs us,
we can easily add a support function that dumps the value without the
anyarray adornment?

> Too bad we did not just store the value in bytea format.

That still seems the right thing to me, not being able in areasonable
way to inspect the default values in the catalog seems worse. We could
have added a new non-array pseudo-type as well, but that's a fair bit of
work...

Greetings,

Andres Freund