Martijn van Oosterhout wrote:
On Mon, Feb 05, 2007 at 12:19:51PM -0500, Andrew Dunstan wrote:
Jim Nasby wrote:
There was also mention of having a means to tell pg_dump not to dump
extensions...
What's the use case for that? What will we do if there are db objects
that depend on some extensions? Given that there will be some uninstall
support, this one seems less necessary.
Well, the use case is someone using tsearch2 on version A and wants to
a do a dump to restore into later version B. It would be helpful if
pg_dump compacted the whole tsearch2 infrastrcutre into a single
"INSTALL tsearch2" command. Obviously, the tsearch2 uninstall script
for version B isn't going to work properly for a database restore from
version A. And this way a dump/restore will pickup any new features
added in the later version.
And if there's an API change everything will blow up.
I would suggest we start with what is (I think) simplest and clearest:
. catalog support via a simple extension->schema(s) map
. initdb installs standard extensions if it finds them, unless told not to
. support for adjusting search path.
If that gets done nicely for 8.3 we'll be doing well.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
