Re: pg_dump with postgis extension dumps rules separately

From: Joe Conway <mail(at)joeconway(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump with postgis extension dumps rules separately
Date: 2013-06-04 02:37:23
Message-ID: 51AD52E3.1020308@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/02/2013 03:10 PM, Dimitri Fontaine wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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-----

Attachment Content-Type Size
fix-extension-ruledeps.03.diff text/x-patch 1.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-06-04 02:57:03 Re: pg_dump with postgis extension dumps rules separately
Previous Message Andrew Dunstan 2013-06-04 01:43:58 Re: create a git symbolic-ref for REL9_3_STABLE