Re: contrib/cube - binary input/output handlers

2021年3月6日(土) 11:21 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>
> 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.
>
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 <kaigai(at)heterodb(dot)com>