On Tue, Nov 17, 2009 at 2:19 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> right...makes sense. converted. one last question: can you save off
>> the blessed TupleDesc (that is, make it static) between invocations of
>> the function (I'm not worried about it changing)?
>
> You could probably
Merlin Moncure writes:
> right...makes sense. converted. one last question: can you save off
> the blessed TupleDesc (that is, make it static) between invocations of
> the function (I'm not worried about it changing)?
You could probably get away with copying it into some long-term memory
contex
On Tue, Nov 17, 2009 at 1:07 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> 2) build the composite via:
>> 2a) TupleDescGetAttInMetadata
>> 2b) BuildTupleFromCStrings
>> 2c) get datum/HeapTupleGetDatum
>
> If it's performance critical, you might want to avoid the extra overhead
> of the At
Merlin Moncure writes:
> 2) build the composite via:
> 2a) TupleDescGetAttInMetadata
> 2b) BuildTupleFromCStrings
> 2c) get datum/HeapTupleGetDatum
If it's performance critical, you might want to avoid the extra overhead
of the AttInMetadata API. Especially if you know the column datatypes
Trying to formulate a good strategy for $subject. The code is
performance critical.
The composite type is simple: (text, text), that needs to be routed to
function call in array form. The #elements in the array is small,
generally less than 10.
The approach I have now is this:
1) look up the oi
