From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | 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 09:26:48 |
Message-ID: | 3A7D2058.17373FFD@tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
> m w <mttf2000(at)yahoo(dot)com> writes:
> > I think this exposes a bug in postgres where either
> > index or table scans (I'm not sure which just yet)
> > treat a zero differently than a non-zero in a varchar.
>
> Embedded zeroes aren't supported in char/varchar/text fields,
> and cannot be supported in a portable fashion, since these datatypes
> rely on functions like strcoll() that don't allow embedded nulls in
> strings.
Is there no simple (i.e. cheap) way to disallow \0 alltogether for
these types then ?
perhaps just strip them out in textin() (or is it text_in()) ?
> It wouldn't surprise me too much if there are inconsistent
> behaviors between indexscans and seqscans for such invalid data.
should'nt they both use the _same_ strcoll() and friends ?
> It doesn't seem real practical for us to examine the output of every
> C-coded function to make sure it produces a valid value of the datatype.
> Illegal returned values are a fault of the function, and ensuing
> misbehaviors are still its fault ...
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.
-------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Mario Weilguni | 2001-02-04 10:12:35 | Implementing an operator in C? |
Previous Message | Hannu Krosing | 2001-02-04 09:18:09 | Re: TODO list: Allow Java server-side programming |