Re: contrib/cube - binary input/output handlers

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

In response to

Responses

Browse pgsql-hackers by date

  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