* Dimitri Fontaine (dimitri@2ndQuadrant.fr) wrote:
> So when you pg_dump | pg_restore from 9.1 into 9.3, if pg_dump were to
> be nitpicky about the version of hstore with the command
>
> CREATE EXTENSION hstore VERSION '1.0';
>
> What would happen is that pg_restore would fail.
>
> That's just the way we maintain contribs.
I'd much rather get an error that says "that version of the extension is
unavailable" than a runtime error when my plpgsql code tries to use a
function whose definition changed between 1.0 and 1.1..
Perhaps we're not ready to go there because of how contrib is built and
shipped, and I can understand that, but that doesn't make it a good
solution. I'm not sure that such an issue should preclude us from
including in-catalog-only extensions from being dump'd out as a set of
objects (ala a schema) and then restored that way (preserving the
version of the extension it was installed at..).
I don't like the idea of having a pg_dump/restore mechanism that
intentionally tries to go out and install the latest version of whatever
extension was installed in the old DB by downloading it from PGXN,
building it, and then installing it... Is that what people are
expecting here?
Thanks,
Stephen
