Ewan Young <kdbase.hack@gmail.com> writes:
> Agreed, that's clearly better. v3 (attached) uses Size for
> GinTuple.keylen (GinBuffer.keylen already was Size), and also for the
> local in _gin_build_tuple(), which was the int that truncated
> VARSIZE_ANY() in the first place.
Am I reading this correctly that you propose using Size for the
length of the key value (keylen) along with int for the length of the
whole tuple (tuplen)?
{
int tuplen; /* length of the whole tuple */
OffsetNumber attrnum; /* attnum of index key */
- uint16 keylen; /* bytes in data for key value */
+ Size keylen; /* bytes in data for key value */
int16 typlen; /* typlen for key */
bool typbyval; /* typbyval for key */
signed char category; /* category: normal or NULL? */
Please explain how that's sane.
I kind of agree with the upthread comment that we should just reject
key lengths exceeding BLCKSZ or so up-front, rather than fooling
around with these field widths. This patch widens GinTuple
noticeably, and will do so more if we also widen tuplen. Is that
free?
regards, tom lane
