Jeff Davis <pg...@j-davis.com> writes:
> On Tue, 2013-12-03 at 14:31 -0500, Tom Lane wrote:
>> Stephen Frost <sfr...@snowman.net> writes:
>>> When it comes to dump/reload, I'd much rather see a mechanism which uses
>>> our deep understanding of the extension's objects (as database objects)
>>> to implement the dump/reload than a text blob which is carried forward
>>> from major version to major version and may even fail to run.
>> Note that we're already doing that in the binary_upgrade code path.
>> I agree that generalizing that approach sounds like a better idea
>> than keeping a text blob around.
> The reason for doing it that way in pg_upgrade was to preserve OIDs for
> types, etc.:
That was *a* reason, but not the only one, I believe.
> That doesn't seem to apply to ordinary dump/reload. Do you think it's
> good for other reasons, as well?
I think Stephen has already argued why it could be a good idea here.
But in a nutshell: it seems like there are two use-cases to be
supported, one where you want "CREATE EXTENSION hstore" to give you
some appropriate version of hstore, and one where you want to restore
exactly what you had on the previous installation. It seems to me that
"exploding" the extension by dumping, rather than suppressing, its
component objects is by far the most reliable way of accomplishing the
latter. To point out just one reason why, we've never made any effort
to prohibit suitably-privileged users from modifying the objects within
an extension. So even if you'd kept around the originally defining
text string, it might not represent current reality. And as for relying
on some URL or other --- whoever proposed that doesn't live in the same
internet I do. URLs aren't immutable, even on days when you can get to
them.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
