Re: COPY does not work with regproc and aclitem
От | Zdenek Kotala |
---|---|
Тема | Re: COPY does not work with regproc and aclitem |
Дата | |
Msg-id | 453D26A9.70702@sun.com обсуждение исходный текст |
Ответ на | Re: COPY does not work with regproc and aclitem (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: COPY does not work with regproc and aclitem
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: