I wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Anything shorter than the shortest possible numeric representation can
>> implicitly be interpreted as some alternate compact representation. I
>> already had a patch that stored small integers in a single
>> NumericDigit without any numeric header at all.

> That's getting well beyond the realm of reason IMHO.  I doubt you can
> merge it with this proposal anyway --- how will you disambiguate from
> zero with a positive dscale ("0.00")?

Hmm, I take that back: it could be merged with this proposal pretty
easily.  Again assuming that we move the POS/NEG/NAN/SHORT "sign"
flags to the first header word, we can have:

Sign=NAN: it's a NAN, regardless of anything else.  We may as well
store NAN as just 2 bytes.

Sign=SHORT: it's a non-NAN with limited weight and dscale range,
as per my proposal.  A zero value would still be only 2 bytes,
but anything else is longer.  (This would be needed only for zero
with nonzero dscale, though.)

Sign=POS or NEG: if length == 2 bytes then interpret the remaining
14 bits as a single NBASE digit, with assumed weight and dscale 0.
This allows storing integers up to +/-9999 in 2 bytes (+ 1 byte
varlena header).  If length > 2 then it is a traditional-format

I'm not entirely convinced this is worth the extra pack/unpack
logic, since said integers would be 4 bytes (+1 byte header) in
the sign=SHORT representation, which is not that much more.
Also, this means at least three different representations of some
values, which is going to be a headache for comparison and hashing.
But the bit-space is there.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to