From: | Jochem van Dieten <jochemd(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Call for 7.5 feature completion |
Date: | 2005-08-29 10:10:06 |
Message-ID: | f96a9b830508290310265f5d9c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 29 Aug 2005 09:56:44 +0200, Harald Fuchs wrote:
> Christopher Kings-Lynne writes:
>>
>> Oh, and 'select rowid, * from table' which returns special rowid
>> column that just incrementally numbers each row.
I think you can pretty much do that already by defining your own
aggregate function. The obvious downside is that you need to put all
the other columns in the GROUP BY clause. There might be some
performance implications from the grouping, but I would presume that a
rowid is most usefull in a situation where you are sorting anyway.
I have to admit this part of the SQL spec is a bit over my head, but
isn't grouping on an <empty grouping set> essentially a no-op?
Implementing that would then take care of having to put all the
coulmns in the GROUP BY clause.
> Why?
Because, although rarely necessary, it is frequently convenient to
have such functionality on the server.
Jochem
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Pflug | 2005-08-29 11:09:35 | Re: dangling lock information? |
Previous Message | Hannu Krosing | 2005-08-29 10:05:55 | Re: dangling lock information? |