Heikki Linnakangas píše v so 31. 01. 2009 v 21:56 +0200: > Robert Haas wrote: > >> Ofcourse, the simplest way to me for handling type changes seems to be > >> to keep the old type OID reserved and have the new version of the type > >> with a new OID. Then the entire problem vanishes. But it was decided a > >> long time ago not to do that. > > > > Why was that decision made? Suppose you have a type called widget and > > you decide it sucks and you want to reimplement it. So in release > > N+1, you rename the old type to old_shitty_widget and leave it with > > the same OID, add the new type under the name widget with a different > > oid, and document that old_shitty_widget should not be used. Then in > > release N+2 you remove old_shitty_widget altogether. > > Yeah, that works. The other approach is to convert the data types along > with the new page format. That works too, and avoids having to keep > around the old type and all that deprecation and stuff. > > I don't remember any hard decision on that, and we're not facing any > data type changes in this release IIRC. It is something we should > consider on a case-by-case basis when we get there. There might be > reasons to do it like that, if for example the old format can't be > converted to new format in a non-lossy fashion (e.g. float-timestamps -> > integer-timestamps). And authors of 3rd party data types are naturally > free to do what they want.
I think there is a confusion, because tuple change size when: 1) on disk structure like tupleheader, varlena, array header ... changed size or 2) datatype representation changed size. We discussed mostly #1 case. It maybe invoked meaning that ALTER TABLE is ignored. But it is not true. I agree with Heikki, data type conversion should be case-by-case and ALTER TABLE is also good solution. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers