Re: Proposed new libpq API

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