To: Glenn Maynard <glennfmaynard@gmail.com>
cc: pgsql-sql@postgresql.org
Subject: Re: Distinct oddity 
In-reply-to: <bd36f99e0905131148k5255d63ai69c76072efa078c5@mail.gmail.com> 
References: <6111.1241879627@sss.pgh.pa.us>
	<C6308BB7.3611D%maximilian.tyrtania@onlinehome.de>
	<bd36f99e0905131148k5255d63ai69c76072efa078c5@mail.gmail.com>
Comments: In-reply-to Glenn Maynard <glennfmaynard@gmail.com>
	message dated "Wed, 13 May 2009 14:48:44 -0400"
Date: Wed, 13 May 2009 15:03:33 -0400
Message-ID: <14780.1242241413@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Glenn Maynard <glennfmaynard@gmail.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