Re: extensible enum types

Gurjeet Singh wrote:
>
>
> This is very similar to Andrew's original suggestion of splitting 32 
> bits into 16+16, but managed by the machine hence no complicated 
> comparison algos needed on our part. Also, since this is all 
> transparent to the SQL interface, our dump-reload cycle or Slony 
> replication, etc. should not be affected either.
>
>

It would break the on-disk representation, though. That's not something 
we want to do any more if it can possibly be avoided. We want to keep 
pg_upgrade working.

cheers

andrew