From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tom Dunstan <pgsql(at)tomd(dot)cc>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Enum proposal / design |
Date: | 2006-08-16 22:52:37 |
Message-ID: | 20060816225237.GU21363@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 16, 2006 at 04:13:43PM -0400, Tom Lane wrote:
> Tom Dunstan <pgsql(at)tomd(dot)cc> writes:
> > I thought the runtime one was kinda cute, actually, but you would have
> > to have duplicate functions for the differently sized types, eg.
> > enum1_out, enum2_out etc since otherwise you wouldn't know what sized
> > parameter you were just handed.
>
> I'm not sure that that matters really. What you are actually going to
> get handed is a Datum that IIRC is right-justified and zero-padded, so
> very probably one function would work for all stored widths. The bigger
> issue I think is the surprise factor if a column gets wider over a dump
> and reload.
Actually, if we're going to support variable-width enums, I think it
makes the most sense to just expose that to the user, since they'll be
able to have a chance of figuring out which size would make the most
sense for a given table (unless you want to add logic to look at the
table's layout...)
If we wanted to provide an idiot-proof version that was "unsized", we
could just make that an alias for a 4 or 8 byte enum.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-08-16 23:02:01 | Re: Enum proposal / design |
Previous Message | Gregory Stark | 2006-08-16 22:48:09 | Re: An Idea for planner hints |