Greg Stark <[EMAIL PROTECTED]> writes:
> Hm. This goes back to the earlier conversation about whether = should ever be
> true for two objects that aren't, well, equal. I thought there was some
> consensus at the time that sorting should impose a superficial ordering on
> items that compare equal bu
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> Thanks for pointing that out. I should have realized that this was the same
> (or at least close to) issue I was thinking would be a problem initially, but
> then I started thinking that '=' promised more than it did and assumed that
> x = y implies fo
On Thu, May 04, 2006 at 02:39:33 -0400,
Tom Lane <[EMAIL PROTECTED]> wrote:
> Bruno Wolff III <[EMAIL PROTECTED]> writes:
> > ... it would be OK to rewrite
> > SELECT DISTINCT x ORDER BY foo(x)
> > as
> > SELECT DISTINCT ON (foo(x), x) x ORDER BY foo(x)
>
> This assumes that x = y implies foo(x)
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> ... it would be OK to rewrite
> SELECT DISTINCT x ORDER BY foo(x)
> as
> SELECT DISTINCT ON (foo(x), x) x ORDER BY foo(x)
This assumes that x = y implies foo(x) = foo(y), which is something
that's not necessarily the case, mainly because a datatype's "
On Thu, May 04, 2006 at 01:13:20 -0400,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> I think it's a fair point that we could allow "SELECT DISTINCT x ORDER BY
> foo(x)" if foo() is stable, but that does not imply that sorting by x is
> interchangeable with sorting by foo(x). foo = abs is a trivial
>
On Thu, May 04, 2006 at 01:32:45 -0400,
Greg Stark <[EMAIL PROTECTED]> wrote:
> Bruno Wolff III <[EMAIL PROTECTED]> writes:
>
> > On Thu, May 04, 2006 at 00:05:16 -0400,
> > Greg Stark <[EMAIL PROTECTED]> wrote:
> > > Bruno Wolff III <[EMAIL PROTECTED]> writes:
> > >
> > > > > Whereas it shou
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> On Thu, May 04, 2006 at 00:05:16 -0400,
> Greg Stark <[EMAIL PROTECTED]> wrote:
> > Bruno Wolff III <[EMAIL PROTECTED]> writes:
> >
> > > > Whereas it shouldn't be hard to prove that this is equivalent:
> > > >
> > > > stark=> explain select col1 f
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> wrote [ baldly summarized ]
>> [ x > y implies upper(x) > upper(y) ]
> I don't think you can assume that that will be true for any locale.
Whether or not that may actually be true for upper() (I share Bruno's
skepticism,
On Thu, May 04, 2006 at 00:05:16 -0400,
Greg Stark <[EMAIL PROTECTED]> wrote:
> Bruno Wolff III <[EMAIL PROTECTED]> writes:
>
> > > Whereas it shouldn't be hard to prove that this is equivalent:
> > >
> > > stark=> explain select col1 from test group by upper(col1),col1 order by
> > > upper(co
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> > Whereas it shouldn't be hard to prove that this is equivalent:
> >
> > stark=> explain select col1 from test group by upper(col1),col1 order by
> > upper(col1);
> > QUERY PLAN
> > -
On Wed, May 03, 2006 at 17:58:07 -0400,
Greg Stark <[EMAIL PROTECTED]> wrote:
>
> Though it's optimized poorly and does a superfluous sort step:
>
> stark=> explain select col1 from test group by col1 order by upper(col1);
> QUERY PLAN
Normally Postgres extends SQL to allow ORDER BY to include arbitrary
expressions not in the select list. However this doesn't seem to work with
SELECT DISTINCT.
stark=> \d test
Table "public.test"
Column | Type | Modifiers
+--+---
col1 | text |
stark=>
12 matches
Mail list logo
