2021年3月6日(土) 1:41 Tom Lane <t...@sss.pgh.pa.us>: > > Kohei KaiGai <kai...@heterodb.com> writes: > > Thanks, the attached patch add cube--1.5 for binary send/recv functions and > > modification of cube type using the new ALTER TYPE. > > Hm, that was already superseded by events (112d411fb). > As long as we get this done for v14, we can just treat it > as an add-on to cube 1.5, so here's a quick rebase onto HEAD. > Thanks for this revising.
> 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? If application saves the raw header field as-is, at least, it can keep the header field without information loss. On the other hand, if cube_send() individually sent num-of-dimension and point flag, an application (that is built for the current version) will drop the bit fields currently unused, but the new version of server may reinterpret the field for something. Of course, it's better to have more careful validation at cuda_recv() when it received the header field. > Also, I don't think "offsetof(NDBOX, x[nitems])" is per project > style. It at least used to be true that MSVC couldn't cope > with that, so we prefer > > offsetof(NDBOX, x) + nitems * sizeof(whatever) > Ok, I'll fix it on the next patch. Best regards, -- HeteroDB, Inc / The PG-Strom Project KaiGai Kohei <kai...@heterodb.com>
