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