Re: Like vs '=' bug with indexing

From: m w <mttf2000(at)yahoo(dot)com>
To: Hannu Krosing <hannu(at)tm(dot)ee>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: m w <mttf2000(at)yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Like vs '=' bug with indexing
Date: 2001-02-04 13:57:32
Message-ID: 20010204135732.17323.qmail@web12407.mail.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


--- Hannu Krosing <hannu(at)tm(dot)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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message pgsql-bugs 2001-02-04 14:31:44 syslog logging setup broken?
Previous Message Jun Kuwamura 2001-02-04 12:19:57 Re: configure problem with krb4 and ssl when compiling 7.1beta4