Re: pg_dump with postgis extension dumps rules separately

From: Joe Conway <mail(at)joeconway(dot)com>
To: postgres hackers <pgsql-hackers(at)postgresql(dot)org>, Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Subject: Re: pg_dump with postgis extension dumps rules separately
Date: 2013-05-28 21:59:20
Message-ID: 51A528B8.1050500@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

On 04/06/2013 04:49 PM, Joe Conway wrote:
> If I create a database and install postgis as an extension, and
> then run pg_dump I get this:
>
> [...] CREATE EXTENSION IF NOT EXISTS postgis WITH SCHEMA public;
> [...] CREATE RULE geometry_columns_delete AS ON DELETE TO
> geometry_columns DO INSTEAD NOTHING; [...]
>
> Shouldn't that CREATE RULE be implicitly part of the CREATE
> EXTENSION?
>
> If so, is this a pg_dump bug, PostGIS bug, or pilot error?
>
> FWIW I see CREATE OR REPLACE RULE statements in the PostGIS
> extension SQL script.

The attached one-liner seems to do the trick. It should probably be
backpatched to 9.1. Remaining questions:

1) Are there other database object types, likely to be included in
extension scripts, that are also lacking dependency records to
their extension?

2) How should we handle already installed extensions, which will still
lack dependency records after this bugfix?

Thanks,

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.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRpSi4AAoJEDfy90M199hlzn4P/j2tgs35b2Y3YoMJHIRDUYmK
uihsKybUYN1uYlS58Igv04lhqWk4MMFFzfwvztENP2SzVysMkA7QoP0BIKy/lF+b
CWwouTLkygnU/a9Mj8TTXMc4YINp4zHOK/XKZaong6zIwCGIXtXp9acl6m7wDI1v
S2FkeRB2dJXyC/Vxv0n9p5JfW75KG6DadJa4ZlcsBx7yV1cwnmePLhoDvsX5fPro
BlD4pFV+GgyW8d65kZxuzIQ/Wy44o0f97yDdeZKi4mzEYooakWzl5iZN5idEBQ3i
LDgjwrCPvod0t8sYGSMaz9qc/fPpWAt4sPkwC6QOCE0u7PJnbZ0oGEGb0JBFGPBc
nV/1sib9KXRfALEUknKYALBqnFhZsaGOTFV9yKhtvscqn/Hmk0mXyocVB9rihcO6
7ipgOgpeqFsS7IQMtiFBUIFPl2ARtD01NKIHbDIKFTQPfss6XXTgIBYmT8W0ldaT
f2jxCEN5SzdCq/G3rx5Z2Dlqau3WIfYiSmWyAG/I2UDBtr7/J7TOSKoJh1+3ntvT
Vxc9b+z8dEz3wE143JOhi1aCNCQ7ybI/K44EhkLjSR4hC6CQiCKlI4OP5gaFj8FJ
YhxTe4FscYTYZVVguBTOKxMzrI1caIt+3LEJ3C7GTkTrQnYc/oZL4v86XlbV24ro
V8IUaO0XFeam7oDxYOZw
=d/qa
-----END PGP SIGNATURE-----

Attachment Content-Type Size
fix-extension-ruledeps.00.diff text/x-patch 526 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-05-28 22:36:45 Re: Planning incompatibilities for Postgres 10.0
Previous Message Alvaro Herrera 2013-05-28 21:55:31 Re: Planning incompatibilities for Postgres 10.0