Re: Fast default stuff versus pg_upgrade

Andrew Dunstan <andrew.dunstan@2ndquadrant.com>

From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org
Date: 2018-06-20T16:51:07Z
Lists: pgsql-hackers

Attachments


On 06/19/2018 10:46 PM, Andres Freund wrote:
> On 2018-06-19 22:41:26 -0400, Andrew Dunstan wrote:
>> 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.
> Why don't you just use OidFunctionCall3? Or simply an explicit
> fmgr_info(), InitFunctionCallInfoData(), FunctionCallInvoke() combo?
>




Thanks for that. I should not code late at night.

Here's a version that works in my testing with Tom's patch making sure 
there's a missing value to migrate applied. Thanks to Alvaro for some 
useful criticism - any errors are of course my responsibility.


cheers

andrew

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

Commits

  1. Allow for pg_upgrade of attributes with missing values