From: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
---|---|
To: | "Zeugswetter Andreas ADI SD" <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at> |
Cc: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Hannu Krosing" <hannu(at)skype(dot)net>, "David Fetter" <david(at)fetter(dot)org>, "Josh Berkus" <Josh(dot)Berkus(at)sun(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: real procedures again (8.4) |
Date: | 2007-10-30 19:19:56 |
Message-ID: | b42b73150710301219j4744d3ddk3b3b70a51b5edd40@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/30/07, Zeugswetter Andreas ADI SD > The background for Quel was,
that when selecting all fields from
> an inheritance hierarchy you got the additional fields of each child.
>
> Thus the field count and types could vary within one cursor.
> Like if you would allow the following:
> select a, b::int from foo
> union all
> select a, c::varchar, d, e from bar
>
> I don't think anybody would want to transfer that idea to sql clients.
> In sql the first statement would define field count, name/alias and
> type.
> The second statement would need to implicitly cast or fail if it does
> not match.
Arrays of composites, along with aggregation tricks, can give you
similar features. The syntax is wierd but powerful in cases like
this. Array support over the protocol and on the client side is
lacking but that's a different topic. That said, returning _complex_
sets is a different problem from returning multiple sets.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2007-10-30 19:41:19 | problem with pgAdmin beta2 on w2k3 |
Previous Message | Marc G. Fournier | 2007-10-30 18:13:46 | Re: Re: [COMMITTERS] pgsql: simple script to pull together a very small (<500k) tar file |