Re: pg_dump with postgis extension dumps rules separately

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

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2013-06-01 11:07:53 -0400, Tom Lane wrote:
>> I don't like this approach much.
>>
>> 1. It does nothing to fix the issue in *existing* databases, which
>> won't have pg_depend entries like this.

> Well, you can now write an extension upgrade script that adds the
> missing dependencies. To me that sounds better than letting it fiddle
> with pg_depend.

Per my point #2, that would be the wrong solution, quite aside from the
wrongness of dumping the fixup burden on the extension author. For one
thing, the extension author has no idea whether his script is being
loaded into a database that has this patch. If it doesn't, adding a
command like this would cause the script to fail outright. If it does,
then the command is unnecessary, since the patch also includes a code
change that adds the dependency.

But in any case, making rules act differently from other table
properties for this purpose seems seriously wrong.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-06-01 15:31:39 Re: detecting binary backup in progress
Previous Message Joe Conway 2013-06-01 15:27:42 Re: detecting binary backup in progress