Re: Distinct oddity

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Glenn Maynard <glennfmaynard(at)gmail(dot)com>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: Distinct oddity
Date: 2009-05-13 19:03:33
Message-ID: 14780.1242241413@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Glenn Maynard <glennfmaynard(at)gmail(dot)com> writes:
> For purposes of DISTINCT, I'd expect any sort order should do; all it
> needs is for equal values to be grouped together. If strcoll() ever
> fails to do that, I'd call it a critical bug--even throwing total
> garbage at it should result in a consistent ordering, even if the
> ordering itself is totally meaningless.

Feel free to complain to the libc authors for your platform --- there
are quite a number of platforms where we know that strcoll does in fact
return garbage (as in inconsistent results) when given garbage input
(which in this case typically means data that's invalid according to
what strcoll thinks the encoding is). That's one reason why we've been
tightening up the encoding-validity enforcement in recent PG releases.

It's not entirely clear to me how things are going wrong in Maximilian's
particular example, but I suspect that the root of it is a problem of
this type.

> Tangentally, is there a better way of rolling back a function than a
> dumb hack like "SELECT 1/0"?

RAISE ERROR?

regards, tom lane

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Gary Stainburn 2009-05-14 13:27:14 update from join
Previous Message Glenn Maynard 2009-05-13 18:48:44 Re: Distinct oddity