On Mon, 2007-06-18 at 12:44 -0400, Tom Lane wrote:
> 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.
> 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.
I think representing zero as compactly as possible is worth the trouble,
so that in itself is enough for me to say Yes. Rest seems good too.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
