I was wondering if this function should be
'wrapped up' and put into the SPI interface.
I did some research and think I could pull
it off.
Currently the tutorial uses this:
> bool
> c_overpaid( TUPLE t, /* the current instance of EMP */
> int4 limit)
> {
> bool isnull = false;
> int4 salary;
>
> salary = (int4) GetAttributeByName(t, "salary", &isnull);
>
> if (isnull)
> return false;
> return salary > limit;
> }
And the regression test uses this:
>
> char
> overpaid(tuple)
> TUPLE tuple;
> {
> bool isnull;
> long salary;
>
> salary = (long) GetAttributeByName(tuple, "salary", &isnull);
> return salary > 699;
> }
Here is a proposal:
a) An explanation between a TupleTableSlot and a HeapTuple / TupleDesc pair. (help?)
Perhaps we call the (TupleTableSlot *) a QueryTuple ? It's called a TUPLE in the two above usages, where a TUPLE
==(void *)
b) Six more functions (overloaded?)
Existing:
Datum SPI_getbinval(HeapTuple, TupleDesc, int, bool *) char *SPI_getvalue (HeapTuple, TupleDesc, int)
Two more by index:
Datum SPI_getbinval(TupleTableSlot, int, bool *) char *SPI_getvalue (TupleTableSlot, int)
Four more by name:
Datum SPI_getbinval(HeapTuple, TupleDesc, char *, bool *) char *SPI_getvalue (HeapTuple, TupleDesc, char *) Datum
SPI_getbinval(TupleTableSlot,char *, bool *) char *SPI_getvalue (TupleTableSlot, char *)
Hmmm. Better yet, is there a way to hide
the difference in the SPI by using a 'smart'
structure?
Clark