From: | "Tom Dunstan" <pgsql(at)tomd(dot)cc> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "David Fetter" <david(at)fetter(dot)org>, "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-18 02:01:33 |
Message-ID: | ca33c0a30806171901w234ef66cubf3e7a841fca1334@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Coming to this thread a bit late as I've been out of email
connectivity for the past week...
On Tue, Jun 17, 2008 at 2:43 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> In any case, trying to define a module as a schema doesn't help at all
> to solve the hard problem, which is how to get this stuff to play nice
> with pg_dump. I think that the agreed-on solution was that pg_dump
> should emit some kind of "LOAD MODULE foo" command, and *not* dump any
> of the individual objects in the module. We can't have that if we try
> to equate modules with schemas instead of making them a new kind of
> object.
This is certainly the end result that I'd like, and intend to work
towards. My main concern has been cases where a module-owned table
gets updated with data that would not be recreated/updated by the LOAD
MODULE in the dump. PostGIS support tables are one example of this,
PL/Java classpath / function information is another. There are
probably many more.
I see two potential solutions:
a) explicitly mark such tables as requiring data to be dumped somehow,
and have pg_dump emit "upsert" statements for all rows in the table.
b) allow modules to define a function that can pg_dump can call to
emit appropriate extra restore commands, above whatever LOAD MODULE
foo does. This has the downside of requiring more work from module
owners (though perhaps a default function that effectively does option
a) could be provided), with a potential upside of allowing module
dumps to become upgrade-friendly by not being tied to a particular
version's table layout.
Thoughts?
Tom
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-06-18 05:27:16 | Re: regex cache |
Previous Message | Jeffrey Baker | 2008-06-18 01:55:45 | Re: pg_dump fails to include sequences, leads to restore fail in any version |