From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [BUGS] We are not following the spec for HAVING without GROUP |
Date: | 2005-03-14 07:26:34 |
Message-ID: | 20050314072634.GA3860@wolff.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Mon, Mar 14, 2005 at 01:52:59 -0500,
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Bruno Wolff III <bruno(at)wolff(dot)to> writes:
> > If someone did a naive implementation of first() and last() aggregates
> > for 8.1, is that something that would likely be accepted?
>
> For the purpose that Greg is suggesting, these would have no advantage
> over min() or max() --- since the system wouldn't know how to optimize
> them --- and they'd be considerably less standard. So my inclination
> would be to say it's a waste of effort.
The case I was thinking of were datatypes without a defined ordering
where max and min wouldn't be usable. But if GROUP BY was going to
changed to allow any columns if the primary key was used in the GROUP
BY clause, I can't see any use for those functions.
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2005-03-14 09:13:23 | Re: [BUGS] We are not following the spec for HAVING without GROUP |
Previous Message | Tom Lane | 2005-03-14 06:54:55 | Re: BUG #1537: alter table statement |
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2005-03-14 07:30:52 | options in conninfo |
Previous Message | Tom Lane | 2005-03-14 07:25:50 | Re: invalidating cached plans |