Re: VARATT_EXTERNAL_GET_POINTER is not quite there yet
От | Gregory Stark |
---|---|
Тема | Re: VARATT_EXTERNAL_GET_POINTER is not quite there yet |
Дата | |
Msg-id | 87y79e9m7t.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: VARATT_EXTERNAL_GET_POINTER is not quite there yet (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: VARATT_EXTERNAL_GET_POINTER is not quite there yet
|
Список | pgsql-hackers |
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > Gregory Stark <stark@enterprisedb.com> writes: >> "Tom Lane" <tgl@sss.pgh.pa.us> writes: >>> I can't say that I find this a nice clean solution; but does anyone have >>> a better one? > >> I'm thinking instead of having struct varlena (which you're not allowed to >> safely use any members of anyways) we should just have a typedef to void*. > > I don't think we could imagine eliminating the struct name, especially > not as a back-patchable solution; there would be too many random > breakages. Yeah, I wasn't thinking to backpatch that. > It might work to change struct varlena's contents to something like > > char vl_len_[4]; /* Do not touch this field directly! */ > char vl_dat[1]; > > so that the compiler wouldn't see it as necessarily having more than > 1-byte alignment. This would also not break any existing code that is > following the rules (touching vl_dat has never been stated to be > verboten). Oh, that would probably fix this problem pretty well. Touching vl_dat is only safe if you've either just allocated the object yourself or you've already detoasted it. In which case we could be using a struct pointer. But if you have a plain old varlena which might be toasted or the return value from GETARG_TEXT_PP then it doesn't make a lot of sense to have a struct pointer at all. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!
В списке pgsql-hackers по дате отправления: