Re: HeapTuple?

mlw <markw(at)mohawksoft(dot)com> writes:
> I should be able to do either:
> create table fubar as select bunch_o_tuples('bla bla');

You might think that, but you can't.

The support for functions returning tuple sets that you are looking for
just plain ain't there. Maybe in 7.2...

It is possible to return a tuple (stuff it into a TupleTableSlot, and
then return a pointer to the slot casted to Datum). But the only thing
that can usefully be done with such a function result is to extract one
datum (column) from it; and the syntax needed to invoke such a function
and then get a column out of its result is so bizarre and limited that
you might as well not bother.

Functions returning sets are possible in 7.1, but they have to return
one value per invocation together with an "I'm not done yet" indication.
See src/backend/utils/fmgr/README in current sources. Again, the
contexts in which such a function can actually be used are limited and
not remarkably helpful.

I'm hoping that we can rethink, redesign, and reimplement all of this
stuff from the ground up in 7.2 or 7.3. Where I'd like to get to is
being able to write

SELECT ... FROM function_returning_tuple_set(params);

but I'm not at all clear yet on what the internal interface to such
a function ought to look like. In particular, should such a function
expect to be called multiple times, or should it be called just once
and stuff multiple result rows into some temporary data structure?
The latter would be easier to program but would be likely to run out
of resources on big result sets.

> Do I have a heap tuple with one entry that acts like a container, and
> create [n] heaptuples with the values, or are heaptuples somehow
> inherently containers.

A heap tuple is just a tuple, ie, one or more Datum values smushed
together. Tuple descriptors are auxiliary data structures that are
used by routines like heap_getattr to extract datums from tuples.
I guess you could call a tuple a container if you wanted, but it's
a pretty simplistic sort of container...

regards, tom lane