From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: VARATT_EXTERNAL_GET_POINTER is not quite there yet |
Date: | 2008-02-21 18:51:50 |
Message-ID: | 87y79e9m7t.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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!
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2008-02-21 19:14:48 | Re: Including PL/PgSQL by default |
Previous Message | Roberts, Jon | 2008-02-21 18:51:33 | Re: Including PL/PgSQL by default |