Re: pg_upgrade vs user created range type extension - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_upgrade vs user created range type extension
Date
Msg-id 31708.1474646158@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_upgrade vs user created range type extension  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: pg_upgrade vs user created range type extension  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> On 09/22/2016 07:33 PM, Tom Lane wrote:
>> If that diagnosis is correct, we should either change pg_dump to not
>> dump that function, or change CREATE TYPE AS RANGE to not auto-create
>> the constructor functions in binary-upgrade mode.  The latter might be
>> more flexible in the long run.

> Yeah, I think your diagnosis is correct. I'm not sure I see the point of 
> the flexibility given that you can't specify a constructor function for 
> range types (if that feature had been available I would probably have 
> used it in this extension).

It turns out that pg_dump already contains logic that's meant to exclude
constructor functions from getting dumped, but it's broken for binary
upgrades from pre-9.6 branches because somebody fat-fingered the AND/OR
nesting in the giant WHERE clauses in getFuncs().  Curiously, it's *not*
broken when dumping from >= 9.6, which explains why I couldn't reproduce
this in HEAD.  It looks like Stephen fixed this while adding the
pg_init_privs logic, while not realizing that he'd left it broken in the
existing cases.

The comment in front of all this is nearly as confused as the code is,
too.  Will fix.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)
Next
From: Andrew Dunstan
Date:
Subject: Re: pg_upgrade vs user created range type extension