Date: Mon, 23 Oct 2006 22:31:37 +0200
From: Zdenek Kotala <Zdenek.Kotala@Sun.COM>
Subject: Re: COPY does not work with regproc and aclitem
In-reply-to: <28143.1161634972@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, pgsql-hackers@postgresql.org
Message-id: <453D26A9.70702@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <453D1B73.2050906@sun.com> <453D1EBF.5070506@dunslane.net>
	<453D201E.3070202@sun.com> <28143.1161634972@sss.pgh.pa.us>
User-Agent: Mail/News 1.5 (X11/20051211)

Tom Lane wrote:
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>> I'm playing with catalog upgrade. The very basic idea of my experiment 
>> is export data from catalog and import it back to the new 
>> initialized/fresh catalog.
> 
> That is never going to work, at least not for any interesting catalogs.
> A system with a "fresh" (I assume you mean empty) pg_proc, for instance,
> is non functional.

No empty, fresh initialized by initdb. I want to copy only "user data" 
which is not created during boostrap.

> 
> A much bigger problem, if you're thinking of this as a component step
> of pg_upgrade, is that you can't use anything at the COPY level of
> detail because it will fail if the new version wants a different catalog
> layout --- for instance, if someone's added a column to the catalog.

Yes, I know about it. It is not problem, I want to prepare "shadow" 
catalog with new structure on old database in separate schema and adjust 
data in these tables. After it I want to make final COPY - data will be 
copied with correct structure.


> The right way to implement pg_upgrade is to transfer the catalog data
> at the SQL-command level of abstraction, ie, "pg_dump -s" and reload.

I'm not sure if it is important, but I think that preserve OID is 
important and SQL level does not allow set OID.

		Zdenek