Re: Enum proposal / design

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tom Dunstan <pgsql(at)tomd(dot)cc>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Enum proposal / design
Date: 2006-08-16 23:02:01
Message-ID: 29335.1155769321@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Dunstan <pgsql(at)tomd(dot)cc> writes:
> Andrew Dunstan wrote:
>> I'm inclined to say let's keep it simple and stay with a fixed 4-byte
>> global size.

> Fair enough. I'm ok with 4 bytes; 8 seemed a bit gratuitous.

If you're gonna fix it at 4 bytes, then I strongly suggest that the
value identifiers actually be OIDs assigned through the standard
OID-generating mechanism, and that the pg_enum table have the structure

standard system OID column unique enum-value identifier
enumtypid OID of enum type it belongs to
enumname name of enum value

unique indexes on:
oid
(enumtypid, enumname)

The advantage of doing this is that you can use the existing, well
debugged, normally-quite-fast mechanisms for generating new unique value
identifiers. Rather than consing up your own slow full-table-scan
mechanism as envisioned in the original proposal.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2006-08-16 23:02:30 Re: An Idea for planner hints
Previous Message Jim C. Nasby 2006-08-16 22:52:37 Re: Enum proposal / design