Re: Proposal: real procedures again (8.4)

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

In response to

Browse pgsql-hackers by date

  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