Re: pg_dump with postgis extension dumps rules separately

Поиск
Список
Период
Сортировка
От Dimitri Fontaine
Тема Re: pg_dump with postgis extension dumps rules separately
Дата
Msg-id m27gicmfyy.fsf@2ndQuadrant.fr
обсуждение исходный текст
Ответ на Re: pg_dump with postgis extension dumps rules separately  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_dump with postgis extension dumps rules separately  (Joe Conway <mail@joeconway.com>)
Список pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Actually, I believe the answer is just that getSchemaData() is doing
>> things in the wrong order:

Each time I have to look at the pg_dump parts I discover new things.
I've been misleading Joe in telling him I though the problem must have
been in extension dependency tracking for rules, without taking the
necessary time to have a real look at the code. Sorry about that.

> BTW, I'm inclined to think it's also wrong that the getEventTriggers()
> call was just added at the end; those things are certainly not table
> subsidiary objects.  I don't know if we allow event triggers to be
> extension members, but if we did, that call would have to occur before
> getExtensionMembership().

Event triggers sure should be allowed as extension members. That leaves
me wondering if there's another possible code arrangement in that
function so that it's easier to maintain. Maybe something with a couple
of structs and a function that knows how to use them to fill in the
variables, but I can see we have some inter-dependencies and some
getSomething functions have quite a specialized API.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Vacuum, Freeze and Analyze: the big picture
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Vacuum, Freeze and Analyze: the big picture