Re: pg_upgrade vs user created range type extension

On 09/23/2016 11:55 AM, Tom Lane wrote:
> 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.
>
>             

Great, Thanks.

cheers

andrew