Re: pg_dump with postgis extension dumps rules separately

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: pg_dump with postgis extension dumps rules separately
Дата
Msg-id 51AD52E3.1020308@joeconway.com
обсуждение исходный текст
Ответ на Re: pg_dump with postgis extension dumps rules separately  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Ответы Re: pg_dump with postgis extension dumps rules separately  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/02/2013 03:10 PM, Dimitri Fontaine wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>>> Actually, I believe the answer is just that getSchemaData() is
>>> doing things in the wrong order:

Indeed Tom, as usual, seems to have the best correct answer :-)

New patch attached works as expected and requires nothing special for
existing databases with installed extensions such as PostGIS with RULEs.


> 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.

I moved getEventTriggers() as well.

I was surprised by a couple of things looking at this code. First,
getRules() is written differently than other table subsidiary objects'
get functions. Secondly, I would have expected
getExtensionMembership() to be recursive -- instead it looks to only
go one level deep. Perhaps the longer term fix would be to identify
extension dependencies recursively, and then the reliance on strict
ordering here could be relaxed. But I don't think we want to make that
change in 9.3 at this point.

Objections to this version?

Joe


- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJRrVLjAAoJEDfy90M199hleA4P/iuGvghfqAo9dogK5e75e7gx
AgL27/WvagrI4mhQp0RQUD3LJx52/XbGqNUMJiGBSuLgGcdwTCyC4yzLAXMEWKD6
x1l1u9mtSAhokk2KjwxdKEzFIzIQ/fYNan5FtXOlgiyq+A7v2hGsFC7ChPgnU6eW
H4nnI94lm3gW7GqxFS3NNjJ0pTDKwAUCYqfoiIjA58WXSUMZoVc5F+DCsS4YjDVG
wve9zf3HVhPxVi/BNCQfRF1grpZfNJFWjSRo1IclCUCqcQWr4BWyXkNuDmSft67S
4UqIkvZyPM+jCoPrJIbqo363CHYICHJ1jfeeYIn+8FnWOtm+fJoXncZbDaKQm9la
iqeHv6qiQzRAq7ui59Nwgo+gSK8IKQYdXilu4wq4LgF0RSb9NTiWldSs+H2FmGLs
k1VNcpGdKlKzp7gOtEAMjd+HWgbYV7Worv7nQY7MJSG81Vnx+LMfiRwSb8Tvrzox
RJcd2zTX3P2ohaczUjRNT6dC9tWT84r+fbelMIOk1ZL2RJixYyzTft7YSrfaz08N
iYL8ho9JPGgO6AX90cpc879HVwkJR3Ffxdu/FPH1AsgtcVO4XUBJlRex1oYWWF+y
FA3Hr+yUhPtyf3Ad/PUGxPpY6ZFTkg1w5prRpDIDKXLnTtWChKrgBsiKow3K5IFA
cQ2OpvmBNiTBkNkbYBKE
=cAP6
-----END PGP SIGNATURE-----

Вложения

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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: create a git symbolic-ref for REL9_3_STABLE
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_dump with postgis extension dumps rules separately