Glenn Maynard 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 t
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 m
I wrote:
> Maximilian Tyrtania writes:
>> am 12.05.2009 19:23 Uhr schrieb Alvaro Herrera unter
>> alvhe...@commandprompt.com:
>>> What platform are you using anyway?
>> Mac OS 10.4.11
> I have some vague recollection that UTF8-using locales don't actually
> work well on OSX ... check the archive
Maximilian Tyrtania writes:
> am 12.05.2009 19:23 Uhr schrieb Alvaro Herrera unter
> alvhe...@commandprompt.com:
>> What platform are you using anyway?
> Mac OS 10.4.11
I have some vague recollection that UTF8-using locales don't actually
work well on OSX ... check the archives ...
am 09.05.2009 16:33 Uhr schrieb Tom Lane unter t...@sss.pgh.pa.us:
> What you need to do is
> dump out the *entire* results of the DISTINCT queries and look for the
> unmatched lines. I'd try dumping to two files, stripping the 'e' with
> sed, and then sort/diff.
Okay, that's what I did, and the
am 12.05.2009 19:23 Uhr schrieb Alvaro Herrera unter
alvhe...@commandprompt.com:
>> FAKDB=# CREATE DATABASE "TestLatin9"
>> FAKDB-# WITH ENCODING='LATIN9'
>> FAKDB-#OWNER=postgres;
>> ERROR: encoding LATIN9 does not match server's locale de_DE
>> DETAIL: The server's LC_CTYPE setting r
am 11.05.2009 16:38 Uhr schrieb Alvaro Herrera unter
alvhe...@commandprompt.com:
>>>Note that the de_DE locale uses Latin9 encoding, which is incompatible
>>>with UTF8.
>>> I'd try checking if the problem is reproducible in
>>> de_DE.utf8 (you need to create a new database for testing, obviously)
Maximilian Tyrtania wrote:
> am 11.05.2009 16:38 Uhr schrieb Alvaro Herrera unter
> alvhe...@commandprompt.com:
>
> >>>Note that the de_DE locale uses Latin9 encoding, which is incompatible
> >>>with UTF8.
> >>> I'd try checking if the problem is reproducible in
> >>> de_DE.utf8 (you need to crea
Maximilian Tyrtania wrote:
> am 10.05.2009 4:58 Uhr schrieb Alvaro Herrera unter
> alvhe...@commandprompt.com:
> > I'd try checking if the problem is reproducible in
> > de_DE.utf8 (you need to create a new database for testing, obviously).
>
> Wait a minute. I need to re- initdb with de_DE.UTF-8
am 10.05.2009 4:58 Uhr schrieb Alvaro Herrera unter
alvhe...@commandprompt.com:
>>> and what locale are you running in?
>>
>> lc_collate | de_DE
>> | Shows the collation order locale.
>> lc_ctype| de_DE
>> | Shows the character classification and cas
Maximilian Tyrtania wrote:
> am 08.05.2009 16:55 Uhr schrieb Rob Sargent unter robsarg...@rocketmail.com:
> > and what locale are you running in?
>
> lc_collate | de_DE
> | Shows the collation order locale.
> lc_ctype| de_DE
> | Shows the character c
On Sat, May 9, 2009 at 10:33 AM, Tom Lane wrote:
> That only proves that adding the 'e' changes the sort order, which is
> completely unsurprising for any non-C locale. What you need to do is
> dump out the *entire* results of the DISTINCT queries and look for the
> unmatched lines. I'd try dump
Maximilian Tyrtania writes:
> FAKDB=# select distinct f.bezeichnung from firmen f order by 1 limit 5
> FAKDB-# ;
>bezeichnung
> -
> sterreichisches Verkehrsbro AG
> \x01Assistenz
> \x10Frohstoff Design & Textilveredelung
> "1. Mittels
am 08.05.2009 16:55 Uhr schrieb Rob Sargent unter robsarg...@rocketmail.com:
>Is firmen a table or a view?
It's a table.
am 08.05.2009 21:52 Uhr schrieb Tom Lane unter t...@sss.pgh.pa.us:
>> It doesn't seem to be related to null values (which wouldn't explain it
>> anyway) nor to this particula
Maximilian Tyrtania writes:
> am 07.05.2009 20:54 Uhr schrieb Scott Marlowe unter scott.marl...@gmail.com:
>> Yeah, that does seem odd. Could it be something like nulls in your
>> data set? just guessing really. If you could make a small test case
>> that shows it happening and allows others to
Is firmen a table or a view?
From: Scott Marlowe
To: Maximilian Tyrtania
Cc: pgsql-sql@postgresql.org
Sent: Friday, May 8, 2009 5:35:21 AM
Subject: Re: [SQL] Distinct oddity
On Fri, May 8, 2009 at 3:28 AM, Maximilian Tyrtania
wrote:
> am 07.05.2009 20
On Fri, May 8, 2009 at 3:28 AM, Maximilian Tyrtania
wrote:
> am 07.05.2009 20:54 Uhr schrieb Scott Marlowe unter scott.marl...@gmail.com:
>
>> On Thu, May 7, 2009 at 2:21 AM, Maximilian Tyrtania
>> wrote:
>>> Hi there,
>>>
>>> does this look right?
>>>
>>> FAKDB=# select count(distinct(f.land)) f
am 07.05.2009 20:54 Uhr schrieb Scott Marlowe unter scott.marl...@gmail.com:
> On Thu, May 7, 2009 at 2:21 AM, Maximilian Tyrtania
> wrote:
>> Hi there,
>>
>> does this look right?
>>
>> FAKDB=# select count(distinct(f.land)) from firmen f where
>> f.typlist='Redaktion';
>> count
>> ---
>>
On Thu, May 7, 2009 at 2:21 AM, Maximilian Tyrtania
wrote:
> Hi there,
>
> does this look right?
>
> FAKDB=# select count(distinct(f.land)) from firmen f where
> f.typlist='Redaktion';
> count
> ---
> 1975
> (1 row)
>
> FAKDB=# select count(distinct(f.land||'1')) from firmen f where
> f.typl
Hi there,
does this look right?
FAKDB=# select count(distinct(f.land)) from firmen f where
f.typlist='Redaktion';
count
---
1975
(1 row)
FAKDB=# select count(distinct(f.land||'1')) from firmen f where
f.typlist='Redaktion';
count
---
4944
(1 row)
FAKDB=# select version();
20 matches
Mail list logo
