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/
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 |