Robert Haas <robertmh...@gmail.com> writes: > On Wed, Jul 28, 2010 at 3:00 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> No, you can do something like this: >> >> typedef union numeric >> { >> uint16 word1; >> numeric_short short; >> numeric_long long; >> } numeric;
> That doesn't quite work because there's also a varlena header that has > to be accounted for, so the third member of the union can't be a > simple uint16. Yeah, you would need an additional layer of struct to represent the numeric with a length word in front of it. I think this is not necessarily bad because it would perhaps open the door to working directly with short-varlena-header values, which is never going to be possible with this: > typedef struct NumericData > { > int32 varlen; > int16 n_header; > union { ... OTOH alignment considerations may make that idea hopeless anyway. > Why n_data as char[1] instead of NumericDigit, you ask? Yes, we'd have to export NumericDigit if we wanted to declare these structs "properly" in numeric.h. I wonder if that decision should be revisited. I'd lean to making the whole struct local to numeric.c though. Is there anyplace else that really ought to see it? >> I hadn't actually looked. I think though that it's a mistake to break >> compatibility on both dscale and weight when you only need to break one. >> Also, weight is *certainly* uninteresting for NaNs since it's not even >> meaningful unless there are digits. dscale could conceivably be worth >> something. > I don't think I'm breaking compatibility on anything. Can you clarify > what part of the code you're referring to here? I'm sort of lost. 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. If we do it the way I'm thinking, dscale would still mean the same in a NaN, and we'd simply be ignoring the weight field (which might or might not be there physically). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers