Re: Expanding the use of FLEXIBLE_ARRAY_MEMBER for declarations like foo[1]
От | Andres Freund |
---|---|
Тема | Re: Expanding the use of FLEXIBLE_ARRAY_MEMBER for declarations like foo[1] |
Дата | |
Msg-id | 20150218130918.GA16383@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Expanding the use of FLEXIBLE_ARRAY_MEMBER for declarations like foo[1] (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Expanding the use of FLEXIBLE_ARRAY_MEMBER for
declarations like foo[1]
|
Список | pgsql-hackers |
On 2015-02-18 17:15:18 +0900, Michael Paquier wrote: > >> - I don't think that the t_bits fields in htup_details.h should be > >> updated either. > > > > Why not? Any not broken code should already use MinHeapTupleSize and > > similar macros. > > Changing t_bits impacts HeapTupleHeaderData, ReorderBufferTupleBuf and > similarly a couple of redo routines in heapam.c using > HeapTupleHeaderData in a couple of structures not placing it at the > end (compiler complains). The compiler will complain if you use a FLEXIBLE_ARRAY_MEMBER in the middle of a struct but not when when you embed a struct that uses it into the middle another struct. At least gcc doesn't and I think it'd be utterly broken if another compiler did that. If there's a compiler that does so, we need to make it define FLEXIBLE_ARRAY_MEMBER to 1. Code embedding structs using *either* [FLEXIBLE_ARRAY_MEMBER] or [1] for variable length obviously has to take care where the variable length part goes. And that what the structs you removed where doing - that's where the t_bits et al go: { ...HeapTupleHeaderData header;char data[MaxHeapTupleSize]; ... } the 'data' bit is just the t_bits + data together. And similar in - 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; The 'data' is where the varlena's vl_dat stuff is stored. > >> Places using a variable-length variable not at the end of a structure > >> are changed with workaround, without impacting what those features do. > > > > I vote for rejecting most of this, except a (corrected version) of the > > pg_authid change. Which doesn't really belong to the rest of the patch > > anyway ;)x > > Changing bytea to use FLEXIBLE_ARRAY_MEMBER requires those changes, or > at least some changes in this area as something with > FLEXIBLE_ARRAY_MEMBER can only be placed at the end of a structure. Again, I think you're confusing things that may not be be done in a single struct, and structs that are embedded in other places. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: