Re: (A) native Windows port
От | Jan Wieck |
---|---|
Тема | Re: (A) native Windows port |
Дата | |
Msg-id | 3D21FB9B.61B924F3@Yahoo.com обсуждение исходный текст |
Ответ на | Re: (A) native Windows port ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>) |
Ответы |
Re: (A) native Windows port
|
Список | pgsql-hackers |
Lamar Owen wrote: > [...] > > And if having a working, usable, Win32 native port gets the subject of good > upgrading higher up the priority list, BY ALL MEANS LET'S SUPPORT WIN32 > NATIVELY! :-) (and I despise Win32....) Hehehe :-) > [...] > Martin O has come up with a 'pg_fsck' utility that, IMHO, holds a great deal > of promise for seamless binary 'in place' upgrading. He has been able to > write code to read multiple versions' database structures -- proving that it > CAN be done. Unfortunately it's not the on-disk binary format of files that causes the big problems. Our dump/initdb/restore sequence is also the solution for system catalog changes. If we add/remove internal functions, there will be changes to pg_proc. When the representation of parsetrees changes, there will be changes to pg_rewrite (dunno how to convert that). Consider adding another attribute to pg_class. You'd have to add a row in pg_attribute, possibly (because it likely isn't added at the end) increment the attno for 50% of all pg_attribute entries, and of course insert an attribute in the middle of all existing pg_class rows ... ewe. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-hackers по дате отправления: