Re: pg_upgrade vs user created range type extension

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_upgrade vs user created range type extension
Дата
Msg-id 31708.1474646158@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_upgrade vs user created range type extension  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: pg_upgrade vs user created range type extension  (Andrew Dunstan <andrew@dunslane.net>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: pg_upgrade vs user created range type extension