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().
>

This unfortunately crashes and burns if we use DirectFunctionCall3 to 
call array_in, because it uses fn_extra. There is the 
CallerFInfoFunctionCall stuff, but it only has 1 and 2 arg variants, and 
array_in takes 3. In retrospect we should probably have added a 3 arg 
form - quite a few input functions take 3 args. Anything else is likely 
to be rather uglier.

Attaching the failing patch. I'll attack this again in the morning.

cheers

andrew



-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services