From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kohei KaiGai <kaigai(at)heterodb(dot)com> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: contrib/cube - binary input/output handlers |
Date: | 2021-03-06 02:21:35 |
Message-ID: | 1526028.1614997295@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kohei KaiGai <kaigai(at)heterodb(dot)com> writes:
> 2021年3月6日(土) 1:41 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> Scanning the code, I have a couple of gripes. I'm not sure it's
>> a good plan to just send the "header" field raw like that ---
>> would breaking it into a dimension field and a point bool be
>> better? In any case, the receive function has to be more careful
>> than this about accepting only valid header values.
>>
> I have a different opinion here.
> Do we never reinterpret the unused header fields (bits 8-30) for another purpose
> in the future version?
Right, that's what to be concerned about.
The best way might be to send the header as-is, as you've done,
but for cube_recv to throw error if the reserved bits aren't
all zero. That way we can't get into a situation where we
aren't sure what's in stored values. If we do expand the header
in future, values should be forward compatible.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2021-03-06 03:19:45 | Re: contrib/cube - binary input/output handlers |
Previous Message | Peter Smith | 2021-03-06 01:49:04 | Re: [HACKERS] logical decoding of two-phase transactions |