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 17:11:33 |
Message-ID: | 1568539.1615050693@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:
> 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.
Works for me.
I noted one additional bug: you have to condition whether to dump
the upper coordinates just on the IS_POINT flag, because that is
all that cube_recv will see. The cube_is_point_internal() hack
can be used in some other places, but not here.
Also, as a matter of style, I didn't like that cube_send was using
the LL_COORD/UR_COORD abstraction but cube_recv wasn't. In the
worst case (if someone tried to change that abstraction) this could
turn into an actual bug, with cube_recv storing the coordinates in
the wrong order. Could have gone either way on which one to change
to look like the other, but I chose to simplify cube_send to look
like cube_recv. This essentially means that we're locking the
binary representation to use the physical storage order of the
coordinates even if someone gets fancy about their meaning.
Pushed with those fixes.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2021-03-06 17:12:50 | Re: [Doc Patch] Clarify that CREATEROLE roles can GRANT default roles |
Previous Message | Magnus Hagander | 2021-03-06 17:06:38 | Re: A new function to wait for the backend exit after termination |