Обсуждение: create index regression fail

Hi,

In current HEAD, create index regression is failing (at least here).
Is anyone else seeing this?
Attached regression.diffs

the query where the regression fails is:

SELECT count(*) FROM dupindexcols
  WHERE f1 > 'LX' and id < 1000 and f1 ~<~ 'YX';

my first theory was that it was because some locale because mine is
es_EC.UTF-8 but the content of the table doesn't justify that,
my second theory was that it was because the index-only scan it's does
but turning off indexonly scan didn't give a different answer

this test case was added in commit
e2c2c2e8b1df7dfdb01e7e6f6191a569ce3c3195 to "Improve planner's
handling of duplicated index column expressions", so this commit broke
something or the count is wrong in the expected result

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación

Jaime Casanova <jaime@2ndquadrant.com> writes:
> the query where the regression fails is:

> SELECT count(*) FROM dupindexcols
>   WHERE f1 > 'LX' and id < 1000 and f1 ~<~ 'YX';

> my first theory was that it was because some locale because mine is
> es_EC.UTF-8 but the content of the table doesn't justify that,

[ experiments... ]  Looks like you're wrong about that.  In ec_EC locale
on my machine, the test accepts these rows that are not accepted in C
locale:
 223 | LLKAAA 738 | LLEAAA

I'll change the lower bound to 'MA' and see if that's any more portable.
        regards, tom lane

On Thu, Jan 12, 2012 at 1:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jaime Casanova <jaime@2ndquadrant.com> writes:
>> the query where the regression fails is:
>
>> SELECT count(*) FROM dupindexcols
>>   WHERE f1 > 'LX' and id < 1000 and f1 ~<~ 'YX';
>
>> my first theory was that it was because some locale because mine is
>> es_EC.UTF-8 but the content of the table doesn't justify that,
>
> [ experiments... ]  Looks like you're wrong about that.  In ec_EC locale
> on my machine, the test accepts these rows that are not accepted in C
> locale:
>
>  223 | LLKAAA
>  738 | LLEAAA
>

oh! i remember now a thread where we talk about glibc not doing the
right thing about this:
http://archives.postgresql.org/message-id/20081215160148.GF4067@alvh.no-ip.org

an update to that post would be that in that time CH and LL where
independent letters but sorted as if they weren't, now they both were
degraded to be a combination of two letters.

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación

Excerpts from Jaime Casanova's message of jue ene 12 16:22:17 -0300 2012:
> On Thu, Jan 12, 2012 at 1:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Jaime Casanova <jaime@2ndquadrant.com> writes:
> >> the query where the regression fails is:
> >
> >> SELECT count(*) FROM dupindexcols
> >>   WHERE f1 > 'LX' and id < 1000 and f1 ~<~ 'YX';
> >
> >> my first theory was that it was because some locale because mine is
> >> es_EC.UTF-8 but the content of the table doesn't justify that,
> >
> > [ experiments... ]  Looks like you're wrong about that.  In ec_EC locale
> > on my machine, the test accepts these rows that are not accepted in C
> > locale:
> >
> >  223 | LLKAAA
> >  738 | LLEAAA
> >
>
> oh! i remember now a thread where we talk about glibc not doing the
> right thing about this:
> http://archives.postgresql.org/message-id/20081215160148.GF4067@alvh.no-ip.org
>
> an update to that post would be that in that time CH and LL where
> independent letters but sorted as if they weren't, now they both were
> degraded to be a combination of two letters.

Yeah, some of these are pretty recent developments by the "real academia
de la lengua", I guess glibc hasn't gotten word about it 100% yet.  On
the other hand I wonder if es_EC is different from other spanish locales
for some reason ...

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support