Re: Removing pg_migrator limitations

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: decibel <decibel(at)decibel(dot)org>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Subject: Re: Removing pg_migrator limitations
Date: 2009-12-23 19:12:36
Message-ID: 11964.1261595556@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

decibel <decibel(at)decibel(dot)org> writes:
> Is there some reason why OIDs were used for ENUM instead of a general sequence? Were we worried about people screwing with the sequence?

No, we were worried about being able to do enum_out without outside
information as to which enum type it is. If you don't mind doubling
the on-disk size of enum values, we could store the enum type OID and
a sequence number instead.

> A sequences would presumably eliminate all these issues. Even if we wanted to disallow user access to the sequence, having something that's not competing with all the other uses of OID would presumably make this a lot simpler.

The fact that it's shared with other uses of OID is 100% not relevant.
A counter shared across all enums would pose the same issues. The
only way to simplify matters would be to have each enum have its own
value numbering, which would mean you need outside information to
identify the associated label.

Even if there were a really solid argument for changing this decision,
doing so would create on-disk compatibility problems that would be
even harder for pg_migrator to fix than what we're discussing now.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-12-23 19:17:32 Re: Removing pg_migrator limitations
Previous Message Bruce Momjian 2009-12-23 19:08:38 Re: Removing pg_migrator limitations