I've been thinking about this and wondered if this is a way to get it
done without too much work.
1. Create an "anyrecord" type to which any record type can be cast.
It's essentially a heaptuple with a tupledesc.
2. "anyrecord" is opaque to the parser, you cannot dereference it, only
output it or pass it to other functions accepting "anyrecord". Possibly
some dynamic languages may be able to reference these.
3. In the output functions printtup_startup/printtup, if any of the
result fields are of type "anyrecord" it defers the 'T' message until
the tuples arrive. When they do it expands the anyrecord and creates
columns from each and sends an appropriate 'T' message.
4. libpq already supports multiple result sets so no problem there.
The effect of this would be that you get multiple result sets, once for
each time the tupledesc changes. As for creating a split without
changing, maybe you need to return a special empty tuple which
signifies end-of-set.
It also occured to me we could just change the "record" type to do
this, but this would change the behaviour of:
test=# select x from test() as x; x
-------(1,2)
(1 row)
to:
a | b
---+---1 | 2
(1 row)
But that's backward incompatable. OTOH, it would mean we could get rid
of the requirement that functions returning "record" must specify a
column definition list in the query. the only restriction is that you
can't dereference it, but that doesn't seem so big a deal.
So, kill a few birds with one stone. Any thoughts?
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
