Re: Proposed new libpq API

Hannu Krosing wrote:

> 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 ;)

What is the essence of your suggestion? The libpq interface, the
protocol or the formatting for psql?

The main problem I can see with the way your idea is going, is that if a
class has a few dozen subclasses, each with a few dozen fields, you
could end up with a couple of thousand resulting columns.

That and it doesn't seem very OO.

> 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 ?

That is the one thing in my mind I'm not certain of. At the moment I
will say that aspect is undefined. Hopefully a clearer answer will
emerge once it is actually working.

--
Chris Bitmead
mailto:chris(at)bitmead(dot)com
http://www.techphoto.org - Photography News, Stuff that Matters