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
