Re: Fast default stuff versus pg_upgrade

On 06/19/2018 01:19 PM, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On 2018-06-19 12:37:52 -0400, Tom Lane wrote:
>>> The problem here is that that function does not exist in 11beta1.
>>> Since adding the "incoming" function is certainly going to require
>>> initdb, we have to be able to dump from the server as it now stands,
>>> or we'll be cutting existing beta testers adrift.
>> It'd probably not be too hard to write a plpgsql replacement for it,
>> should it come to that. Obviously it'd be nicer to not require users to
>> create that, but ...
> After some thought, I think it's not that hard to get the support function
> to accept the anyarray string form.  I was worried about issues like
> whether float8 values would restore exactly, but really that's no worse
> than a dump/reload today.  Basically, the support function would just need
> to extract the target attribute's type and typmod from the pg_attribute
> row, then call array_in().
>
> I wonder though whether there are any interesting corner cases along
> this line:
>
> 1. Create a column with a fast default.
>
> 2. Sometime later, alter the column so that the fast default value
> is no longer a legal value.  If the fast default isn't in active use
> in the table, the ALTER would go through; but if it does not remove
> the attmissingval entry, then ...
>
> 3. Subsequently, pg_upgrade fails when the support function tries to
> pass the attmissingval entry through the type input function.
>
> The kind of case where this might fail is reducing the allowed
> max len (typmod) for a varchar column.  I think ALTER TABLE is
> smart enough to not rewrite the table for that, so that there
> wouldn't be anything causing the fast default to get removed.
>
>     


My experimentation showed this causing a rewrite. I think it only skips 
the rewrite if you make the allowed length greater, not smaller.

cheers

andrew