Re: Crash in pgCrypto?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Fetter <david(at)fetter(dot)org>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Mario Weilguni <mweilguni(at)sime(dot)com>
Subject: Re: Crash in pgCrypto?
Date: 2008-06-17 15:28:58
Message-ID: 22404.1213716538@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Fetter <david(at)fetter(dot)org> writes:
> It's not quite that simple. Let's say you're *developing* a module.
> I don't see any way to play with it in the separate module proposal,
> where I *do* see a whole extra non-orthogonal feature where none is
> needed.

The claim that no new feature is needed is complete rubbish. The
*main* thing that we need to get out of a module concept is to have
pg_dump know that it should not dump objects that are part of a
module (at least in the default case). That can't be the behavior
for schemas.

You could imagine implementing modules as specially marked schemas,
perhaps, but I don't see any particular advantage to that. In
particular, I don't want to force people to play around with
search_path in order to use modules.

> Here's how what I'm proposing would work:

> 1. Create a way for schemas themselves to depend on other schemas,
> *not* on the stuff inside.

That does not actually solve any problem we need solved.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-06-17 15:41:19 Re: sh -> pl
Previous Message Joshua D. Drake 2008-06-17 15:15:43 Re: Crash in pgCrypto?