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
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? |