Chris Bitmead wrote:
>
> I've been thinking about what changes are necessary to the libpq
> interface to support returning variable type tuples. This was
> discussed a number of months back but an exact interface wasn't nailed
> down.
Let me propose an additional possible solution for the most common case
needing to return multiple types of tuples, the case of select ** --
just
have a tupletype for each tuple, possibly as an implies field and return
NULL
for missing fields (returning nulls is cheap - each only occupies one
bit)
so that
SELECT user
UNION
SELECT nextval('myseq');
would return a result with the following structure
type() | user (text) | nextval(int)
----------------------------------- t1 | postgres | NULL t2 | NULL | 1
such way of returning tuples could possibly make also non-OO folks happy
as the result will still be table-shaped ;)
> Let me then put forward the following suggestion open for comment. The
> suggestion is very similar to the original postgres solution to this
> problem. What I have added is some consideration of how a streaming
> interface should work, and hopefully I will incorporate that
> enhancement while I'm at it.
>
> Into libpq will be (re)introduced the concept of a group. Tuples which
> are returned will be from a finite number of different layouts.
>
> Thus there will be an API PQnfieldsGroup(PGresult, group_num). And
> similar for PQftypeGroup etc. There will be a PQgroup(PGresult,
> tuple_num) which will tell you which group any given tuple belongs to.
Seems good ;).
Will the group carry only structurte or will it have some "higher"
meaning -
i.e. will rows selected form two different tables with the same
structure
be in the same group ?
----------
Hannu
