2021年3月6日(土) 11:21 Tom Lane <t...@sss.pgh.pa.us>: > > Kohei KaiGai <kai...@heterodb.com> writes: > > 2021年3月6日(土) 1:41 Tom Lane <t...@sss.pgh.pa.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. > Ok, the attached v4 sends the raw header as-is, then cube_recv validates the header. If num-of-dimension is larger than CUBE_MAX_DIM, it is obviously unused bits (8-30) are used or out of the range.
It also changes the manner of offsetof() as you suggested. Best regards, -- HeteroDB, Inc / The PG-Strom Project KaiGai Kohei <kai...@heterodb.com>
pgsql-cube-binary-inout-handler.v4.patch
Description: Binary data
