Re: SQL syntax extentions - to put postgres ahead in the race - Mailing list pgsql-sql

From Tom Lane
Subject Re: SQL syntax extentions - to put postgres ahead in the race
Date
Msg-id 8583.1091776047@sss.pgh.pa.us
Whole thread Raw
In response to Re: SQL syntax extentions - to put postgres ahead in the race  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Responses Re: SQL syntax extentions - to put postgres ahead in the race  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-sql
Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> On Thu, 5 Aug 2004, Ram Nathaniel wrote:
>> 2) aggregated concatenation:

> Theoretically, you should be able to do this right now in PostgreSQL with
> user defined aggregates (although you can't pass a second argument
> currently for the separator).

There's nothing particularly stopping us from supporting
multiple-argument aggregates, except a lack of round tuits.
(I suppose we'd want to rethink the syntax of CREATE AGGREGATE,
but otherwise it ought to be pretty straightforward.)

> I believe that an ordered subquery in FROM
> will currently allow you to get an ordered aggregate, or perhaps you'd
> have to turn off hash aggregation, but I think you should be able to get
> it to keep the ordering.

I think you would want to ORDER BY twice:
   SELECT class, list(student) from(select class, student from grades order by class, student) ss   order by class;

It looks like (at least in CVS tip) planner.c will take into account the
relative costs of doing a GroupAgg vs doing a HashAgg and re-sorting,
but I'm too tired to try it right now...
        regards, tom lane


pgsql-sql by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: SQL syntax extentions - to put postgres ahead in the race
Next
From: "Antonis Antoniou"
Date:
Subject: retrieve the tables names based on the owner