> 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 that there's no straight substitute for the actual
feature. The closest you'll get is a domain, but they don't
order stuff properly. Efficiency is clearly a driving factor
as well, though, hence my reluctance to store 8 bytes on
disk. :)
> ...
> 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
> those as fixed sized data types?
It also affects composite types. And some user types out
there like Martijn's tagged types.
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 you put it: if a general solution to
that problem can be found which does fall afoul of the
security issues that were the reason for multi-argument
output functions to be killed off in the first place, then
great, and enums can directly benefit.
Cheers
Tom
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
