From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Gary Chambers <gwchamb(at)gmail(dot)com>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #3682: Incomplete database restore |
Date: | 2007-10-22 07:29:45 |
Message-ID: | 20071022072945.GA9675@svr2.hagander.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sun, Oct 21, 2007 at 04:24:05PM -0400, Tom Lane wrote:
> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> > Perhaps we should include the functionality of that script in pg_dump.
>
> I'm pretty uncomfortable with the notion of having pg_dump deliberately
> throw data away. Another problem is that even if we did that, it would
> only help people who dumped their old DB with 8.3 pg_dump.
Don't we already say you should use 8.3 pg_dump to dump your old db when
upgrading?
> Having the functionality in pg_restore would be a little saner, but it
> still seems like a big wart.
>
> As for the datatype issue, I wonder whether we should just advise people
> to do
> CREATE DOMAIN public.tsvector AS pg_catalog.tsvector;
> before restoring?
Unless it's something that's only temporary, I would prefer something that
would migrate the actual schema instead of requiring a domain sitting there
*forever*. The overhead isn't large, but it's there...
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2007-10-22 09:32:24 | Re: BUG #3682: Incomplete database restore |
Previous Message | Gary Chambers | 2007-10-22 03:17:49 | Re: BUG #3682: Incomplete database restore |