Michael Paquier <michael.paqu...@gmail.com> writes: > On Thu, Feb 19, 2015 at 7:29 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Moreover, if we have any code that is assuming such cases are okay, it >> probably needs a second look. Isn't this situation effectively assuming >> that a variable-length array is fixed-length?
> AFAIK, switching a bunch of things to use FLEXIBLE_ARRAY_MEMBER has > put a couple of things in light that could be revisited: > 1) tuptoaster.c, with this declaration of varlena: > struct > { > struct varlena hdr; > char data[TOAST_MAX_CHUNK_SIZE]; /* make > struct big enough */ > int32 align_it; /* ensure struct is > aligned well enough */ > } chunk_data; I'm pretty sure that thing ought to be a union, not a struct. > 2) inv_api.c with this thing: > struct > { > bytea hdr; > char data[LOBLKSIZE]; /* make struct > big enough */ > int32 align_it; /* ensure struct is > aligned well enough */ > } workbuf; And probably this too. > 3) heapam.c in three places with HeapTupleHeaderData: > struct > { > HeapTupleHeaderData hdr; > char data[MaxHeapTupleSize]; > } tbuf; And this, though I'm not sure if we'd have to change the size of the padding data[] member. > 5) reorderbuffer.h with its use of HeapTupleHeaderData: Hmm. Andres will have to answer for that one ;-) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers