From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_upgrade vs user created range type extension |
Date: | 2016-09-23 17:49:22 |
Message-ID: | 8e8c0f13-7fc4-2a55-0dea-8b5963ff0f5d@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 09/23/2016 11:55 AM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Breen Hagan | 2016-09-23 17:55:14 | Re: BUG #13755: pgwin32_is_service not checking if SECURITY_SERVICE_SID is disabled |
Previous Message | Tom Lane | 2016-09-23 15:55:58 | Re: pg_upgrade vs user created range type extension |