On Thu, Jul 29, 2010 at 4:37 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, Jul 29, 2010 at 1:20 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers