Re: pg_dump with postgis extension dumps rules separately - Mailing list pgsql-hackers

From Joe Conway
Subject Re: pg_dump with postgis extension dumps rules separately
Date
Msg-id 51A528B8.1050500@joeconway.com
Whole thread Raw
In response to pg_dump with postgis extension dumps rules separately  (Joe Conway <mail@joeconway.com>)
Responses Re: pg_dump with postgis extension dumps rules separately  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List 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

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Planning incompatibilities for Postgres 10.0
Next
From: Bruce Momjian
Date:
Subject: Re: Planning incompatibilities for Postgres 10.0