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.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
