Chris Bitmead wrote:
>
> 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?
I was hoping it to cover all of them, but it may not be that simple on
closer ispection ;(
> 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.
Yes. In fact I will end up with that number anyway, only that each tuple
does not have all of them in case of returning multiple types of tuples.
I still insist that the _overhead_ from returning such colums is quite
small as each null is only one _bit_
> That and it doesn't seem very OO.
no, it does not, unless we pretend that what "SELECT **" returns is all
superobjects which in fact do have all the NULL fields, only they have
value NULL :)
otoh, doing things that way could "hide" the OO-ness from tools that
don't like it.
-------
BTW, how does one subscribe to pgsql-oo@postgresql.org list ?
I tried, but my response mail said something like
"processing your subscription successful, you are _NOT_ subscribed to
list"
I got the same result with other new lists ;(
----------
Hannu
