Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jul 28, 2010 at 3:00 PM, Tom Lane <tgl@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