Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

In response to


pgsql-general by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group