On Thu, Jul 29, 2010 at 4:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Jul 29, 2010 at 1:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> On-disk is what I'm thinking about. Right now, a NaN's first word is
>>> all dscale except the sign bits. You're proposing to change that
>>> but I think it's unnecessary to do so.
>
>> *Where* am I proposing this?
>
> Um, your patch has the comment
>
> ! * If the high bits of n_scale_dscale are NUMERIC_NAN, the two-byte header
> ! * format is also used, but the low bits of n_scale_dscale are discarded in
> ! * this case.
>
> but now that I look a bit more closely, I don't think that's what the
> code is doing. You've got the NUMERIC_DSCALE and NUMERIC_WEIGHT access
> macros testing specifically for NUMERIC_IS_SHORT, not for high-bit-set
> which I think is what I was assuming they'd do. So actually that code
> is good as is: a NAN still has the old header format. It's just the
> comment that's wrong.
OK. I think you're misinterpreting the point of that comment, which
may mean that it needs some clarification. By "the two byte header
format is also used", I think I really meant "the header (and in fact
the entire value) is just 2 bytes". Really, the low order bits have
neither the old interpretation nor the new interpretation: they don't
have any interpretation at all - they're completely meaningless.
That's what the part after the word "but" was intended to clarify.
Every routine in numeric.c checks for NUMERIC_IS_NAN() and gives it
some special handling before doing anything else, so NUMERIC_WEIGHT()
and NUMERIC_DSCALE() are never called in that case.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
