"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> I think it would be good to have something, so that people are
> occasionally reminded about these things. That's a good way to help
> shake ideas out.
I think the only reason there aren't more outrageous dreamworld ideas in the
TODO is that people cam
On Thu, Aug 17, 2006 at 08:02:32PM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Jim C. Nasby wrote:
> > >> If there was a mechanism to obtain
> > >> field widths from the catalog there would be no need to store the
> > >> field width in each tupl
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Jim C. Nasby wrote:
> >> If there was a mechanism to obtain
> >> field widths from the catalog there would be no need to store the
> >> field width in each tuple. This would be useful for other types as
> >> well (UUID and ENUM, for ex
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Jim C. Nasby wrote:
>> If there was a mechanism to obtain
>> field widths from the catalog there would be no need to store the
>> field width in each tuple. This would be useful for other types as
>> well (UUID and ENUM, for example).
> I don't think the
Jim C. Nasby wrote:
> On Wed, Aug 16, 2006 at 07:21:06PM -0400, Gregory Stark wrote:
> > This is the same issue we have with char(n) and numeric(x,y) already. If we
> > found a general solution for getting the type name to the enum would it also
> > help getting the typmod to char(n) and numeric(x,
On Wed, Aug 16, 2006 at 07:21:06PM -0400, Gregory Stark wrote:
> This is the same issue we have with char(n) and numeric(x,y) already. If we
> found a general solution for getting the type name to the enum would it also
> help getting the typmod to char(n) and numeric(x,y)? Would it let us store
>
Greg Stark wrote:
"Tom Dunstan" <[EMAIL PROTECTED]> writes:
I didn't really want to go down that path in this thread
since it would turn what should be a fairly non-intrusive
patch to add a new type into a big thing, and I really just
wanted to get enums in. :) I tend to think of it the othe
"Tom Dunstan" <[EMAIL PROTECTED]> writes:
> I didn't really want to go down that path in this thread
> since it would turn what should be a fairly non-intrusive
> patch to add a new type into a big thing, and I really just
> wanted to get enums in. :) I tend to think of it the other
> way around f
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > I think this is excessive concern for bit-shaving.
>
> Egads. bit-shaving is *important*. If it's 8 bytes you
> could just use a char(4) and store 4 character text codes
> instead. The whole reason to want this feature is
> precisely for bit-shaving.
Tom Lane <[EMAIL PROTECTED]> writes:
> 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
...
> The advantage of doing this is that you
Tom Lane <[EMAIL PROTECTED]> writes:
> I think this is excessive concern for bit-shaving. Make the on-disk
> representation be 8 bytes instead of 4, then you can store the OID
> directly and have no need for the separate identifier concept. This
> in turn eliminates one index, one syscache, and
Tom Dunstan <[EMAIL PROTECTED]> 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 identi
On Wed, Aug 16, 2006 at 04:13:43PM -0400, Tom Lane wrote:
> Tom Dunstan <[EMAIL PROTECTED]> 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 woul
Tom Dunstan <[EMAIL PROTECTED]> 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 s
Andrew Dunstan wrote:
Even more radical: do it at runtime. You could assign the typlen
(stored width) of an enum type at creation time on the basis of the
largest identifier it contains. This might be a bit too weird because
enums created earlier would have a size advantage over those created
(I had a private bet with myself that Tom Lane would object to the "bit
shaving" ;-) )
Tom Lane wrote:
Ok, I'll run one more idea up the flagpole before giving up on a 4 byte
on disk representation. :) How about assigning a unique 4 byte id to
each enum value, and storing that on disk. This
Tom Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think this is excessive concern for bit-shaving. Make the on-disk
>> representation be 8 bytes instead of 4, then you can store the OID
>> directly and have no need for the separate identifier concept.
> That's all true. It's a bit de
Tom Lane wrote:
Tom Dunstan <[EMAIL PROTECTED]> writes:
On disk, enums will occupy 4 bytes: the high 22 bits will be an enum
identifier, with the bottom 10 bits being the enum value. This allows
1024 values for a given enum, and 2^22 different enum types, both of
which should be heaps. The exact
Tom Dunstan <[EMAIL PROTECTED]> writes:
> Andrew and I got together and worked out a more detailed idea of how we
> want to add enums to the postgresql core. This follows on from his
> original enumkit prototype last year [1]. Here's a more formal proposal
> / design with what we came up with. C
We forgot to mention that we'll need to implement domains over enums and
arrays of enums too.
cheers
andrew
Tom Dunstan wrote:
> Hi guys
>
> Andrew and I got together and worked out a more detailed idea of how we
> want to add enums to the postgresql core. This follows on from his
> original e
Hi guys
Andrew and I got together and worked out a more detailed idea of how we
want to add enums to the postgresql core. This follows on from his
original enumkit prototype last year [1]. Here's a more formal proposal
/ design with what we came up with. Comments / criticism hereby solicited.
21 matches
Mail list logo
