Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2007-10-30 19:41:19
Subject: problem with pgAdmin beta2 on w2k3
Previous:From: Marc G. FournierDate: 2007-10-30 18:13:46
Subject: Re: Re: [COMMITTERS] pgsql: simple script to pull together a very small (<500k) tar file

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group