Re: Crash in pgCrypto? - Mailing list pgsql-hackers

From Robert Treat
Subject Re: Crash in pgCrypto?
Date
Msg-id 200806170854.43470.xzilla@users.sourceforge.net
Whole thread Raw
In response to Re: Crash in pgCrypto?  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Crash in pgCrypto?  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On Monday 16 June 2008 21:12:23 Andrew Dunstan wrote:
> David Fetter wrote:
> > On Mon, Jun 16, 2008 at 06:00:33PM -0400, Andrew Dunstan wrote:
> >>> I, too, would be happy to do the legwork on this one.  I believe
> >>> we'd want to have both per-db and per-role settings for
> >>> search_path.  What's involved with creating that latter?
> >>
> >> Proper support for module install / uninstall will be a far better
> >> solution. Why would you wast your time on something that will be at
> >> best half-baked?
> >
> > Maybe I'm missing something big, but I don't quite see what
> > constitutes "proper" that doesn't involve the module's having at least
> > one schema to itself.  Does this mean we'd be freezing modules in
> > their first-deployed form?  It seems to me that DROP SCHEMA ...
> > CASCADE is just the right level of modularity combined with
> > flexibility post-installation.
>
> ISTM that "uninstall foomodule" will be a whole lot nicer.
>
> If we record all the objects that the module contains, then we would
> just drop them.
>
> The module could involve one schema, or several schemas, or none.
>
> Maybe that's the "something big".
>

I think individual schemas is nicer, since it has helped me getting around 
these problems for years now, while module support is still vaporware.  
However, I am looking forward to your patch. :-)

BTW, I am suspecting part of your support will be giving pg_dump -m and -M 
flags to control dumping or ignoring of specific modules? 

-- 
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pltcl broken on tcl8.5 ?
Next
From: Jeff
Date:
Subject: Re: Reducing overhead for repeat de-TOASTing