Re: Tagged types module and varlena changes

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl>
Cc: postgres list <pgsql-general(at)postgresql(dot)org>
Subject: Re: Tagged types module and varlena changes
Date: 2009-08-26 13:33:17
Message-ID: 407d949e0908260633h717ac7c0o770e4937f5c9ea58@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Aug 26, 2009 at 1:14 PM, Alban
Hertroys<dalroi(at)solfertje(dot)student(dot)utwente(dot)nl> wrote:
>> struct varlena* tv = (struct varlena*)tt_palloc( VARSIZE( datum ) );
>>
>> tv->vl_len = VARSIZE( datum ) - sizeof(Oid);
>> memcpy( tv->vl_dat,
>>        &((struct taggedtypev*)DatumGetPointer( datum ))->val,
>>        VARSIZE(datum) - sizeof(Oid) - VARHDRSZ );
>> return PointerGetDatum( tv ) ;
>
>
> This doesn't compile anymore as the vl_len member of struct varlena no
> longer exists and we're supposed to use the SET_VARSIZE macro instead now. I
> tried that, but then the memcpy bails out due to the size calculation being
> wrong. I don't know enough about varlena usage to figure out what the
> correct way of calculating the size for memcpy is, or whether that approach
> is at all feasable with the current varlena implementation. What should the
> above read?
>

With the SET_VARSIZE the above should work *as long as datum is not
toasted (or packed)*. If it's been detoasted then that's good, or if
it was freshly generated and not stored in a tuple then it should be
good too.

If it's not guaranteed to be detoasted then you probably should be
adding detoast calls since the Oid will have alignment requirements.
Otherwise you could just use VARSIZE_ANY_EXHDR()

It's generally a good thing to rename the vl_len field to something
like _vl_len to catch anyplace else that's referring directly to it.
That will never work any more, neither for setting it nor for reading
it. They all need to be converted to use VARSIZE and SET_VARSIZE

I haven't looked at the rest of the code to see if the general
approach is still reasonable. The varlena changes shouldn't be fatal
though.
--
greg
http://mit.edu/~gsstark/resume.pdf

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Matthew Wakeling 2009-08-26 14:07:45 Re: Fwd: How to create a multi-column index with 2 dates using 'gist'?
Previous Message Ries van Twisk 2009-08-26 12:44:33 Re: best practise/pattern for large OR / LIKE searches