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 tuple. This would be
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 came
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 from how
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 other
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
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,y)?
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 there is
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 example).
I
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
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.
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:
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 depressing
(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
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
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 sure
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 wouldn't
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 identifiers
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 one
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 can
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.
Well, and
20 matches
Mail list logo
