I wonder if a macro system might be warranted - then have max be a macro
instead of an aggregate. However, I don't know exactly how that would
work since it involves the whole statement. Anyway, just an idea to
hopefully spur someone else's thinking cap :)
Jon
On Wed, 11 Jun 2003, Tom Lane wrote:
> "Dann Corbit" <DCorbit@connx.com> writes:
> > Is this a poorly designed hack:
> > Select max(expression) from <join> where <filter>
>
> Well, to start with, any nonempty WHERE probably invalidates the
> optimization, and I doubt it works if there's a join rather than a
> single table involved. But you're just handwaving --- the devil is in
> the details. How will you identify which aggregates are MIN and MAX
> (no, I don't like the idea of relying on the names; remember we have
> an extensible set of aggregates)? What will you do when there are
> multiple aggregates in the command --- or more generally, how complex a
> context for the aggregate call are you going to be able to support?
> Where exactly is this transformation going to occur in the planning
> pipeline, and how many cycles will we waste checking for the possible
> transform in cases where it doesn't apply? Questions like these are
> where we've gotten bogged down in the past. You might care to consult
> the pgsql-hackers archives for past discussions.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>