Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> writes:
>> Uh, why worry? If you had an application that depended in any way
>> shape or form on the SET type, then I already broke it ...
> Wasn't it a pg_upgrade consideration or something?
No, I thought the discussion was about whether client code could get
away with hard-coding OID values for popular types. ISTM it's
sufficient to promise that a type's OID won't change while the type
exists. If we remove a type that your client depends on, you've got
worse problems than what the OID is.
regards, tom lane