* Jeff Davis (pg...@j-davis.com) wrote: > On Mon, 2013-12-02 at 15:44 -0500, Stephen Frost wrote: > > How are we going to handle new keywords > > being added in new major versions? A pg_dump of the extension template > > script is then going to be loaded into the new major version but will > > not actually be able to be run because it'll error out... > > Elsewhere in the thread you argued that the version of an extension > should be preserved across dump/reload. Surely a given version of the > extension corresponds to a specific set of SQL commands (specifically, > the SQL text blob on PGXN), so it *should* error out.
I *do* think the version should be preserved (though I admit that the
argument about things released with PG does make some sense). My point
above is that if we dump the text blob out and then just rerun it, it
might not work, but if we use pg_dump and dump the extension out as
database objects (using the newer version of pg_dump, as we always
recommend..), then it's certainly more likely to work even in the face
of new keywords and the like which change between releases.
> Otherwise you end up with a weird situation where upgrading a 9.4
> install to 9.5 allows you to keep version 1.2 of some extension, but 1.2
> won't install directly to 9.5. (By the way, I think this is a problem
> with pg_upgrade currently.)
Hmm. I'll grant, that's an interesting situation to consider, but I'm
trying to figure out why it's better to make it always break, both on
initial installation and when doing a restore from a backup, than only
have it (most likely anyway) break on initial installation (to a newer
version that may not have existed originally).
> You're fighting pretty hard against text blobs, but at the same time
> saying that we should be able to fully make use of existing PGXN
> extensions, which contain text blobs of SQL. And extension authors are
> versioning their SQL blobs, not some abstract concepts internal to
> postgres and the catalogs.
I don't want text blobs in the backend catalogs. I'm not argueing
against text blobs in general (that'd be kinda hard to do..).
> Just because we start with blobs from PGXN doesn't mean we need to use
> blobs everywhere; but I think you're too quick to rule them out.
Perhaps, but I really don't see the point of putting a text blob into
the database for a set of objects that we're just going to create in the
next moment. That would be, from my point of view anyway, akin to
storing 'CREATE TABLE' statements in the catalog next to the actual
definition of the table in pg_class/pg_attribute.
Thanks,
Stephen
signature.asc
Description: Digital signature
