Re: Like vs '=' bug with indexing - Mailing list pgsql-hackers

From m w
Subject Re: Like vs '=' bug with indexing
Date
Msg-id 20010204135732.17323.qmail@web12407.mail.yahoo.com
Whole thread Raw
In response to Re: Like vs '=' bug with indexing  (Hannu Krosing <hannu@tm.ee>)
Responses Re: Like vs '=' bug with indexing  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
--- Hannu Krosing <hannu@tm.ee> wrote:

> Should we not examine "the _possible_ outputs of
> every C-coded function 
> to make sure it produces a valid value of the
> datatype" ;)
> 
> For me producing an invalid data for a datatype
> seems very much like 
> a bug and it _should_ be reported.

No, I think Tom is right, there should be no
validation on C functions incorporated into Postgres
by users. Who wants that overhead in a production
system?

However, I think when the same SQL query produces
different results when you add an index, speaks of an
inconsistency in the system, which could be the source
of other problems.

I have seen a couple posts where results from an index
scan are not the same as the results from a table
scan, granted they were language issues, but still, my
gut tells me if I set the length of a variable to x,
and a trailing zero is included, the system should
either fail consistently or work consistently. I don't
care which, it should just be consistent.

Inconsistent behavior indicates that a different
matching algorithm is used if one uses an index
instead of a table scan. That scares me.

__________________________________________________
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/


pgsql-hackers by date:

Previous
From: Jun Kuwamura
Date:
Subject: Re: configure problem with krb4 and ssl when compiling 7.1beta4
Next
From: Peter Eisentraut
Date:
Subject: Re: [PATCHES] A Sparc/Linux patch (for 7.1), and a Linux rc.d/init.d script....