| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Cat <cat(at)zip(dot)com(dot)au> |
| Cc: | Chuck Roberts <croberts(at)gilsongraphics(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Chris Campbell <ccampbell(at)cascadeds(dot)com>, PSql novice list <pgsql-novice(at)postgresql(dot)org> |
| Subject: | Re: Trouble with IN operator |
| Date: | 2017-02-04 05:44:17 |
| Message-ID: | CAKFQuwY9HFi_zZY-eaSPo_0jiqu4+w1f88kV68vg9pfjJ28RVQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-novice |
On Friday, February 3, 2017, Cat <cat(at)zip(dot)com(dot)au> wrote:
> On Fri, Feb 03, 2017 at 01:48:49PM -0500, Chuck Roberts wrote:
> > Yes there is data that matches the criteria of the IN condition. When I
> > remove the clause with the IN, I get all kinds of records that look like
> > they match the criteria. The tbl.costcenter is a string of 3 characters,
> > but it only contains numbers which are zero padded, like '001', '540',
> > '900'. There should be no room for odd characters, even though users do
> > enter this number.
> >
> > Also I tried a case-insensitive regex, and that didn't work either. Ex:
> > AND (tbl.costcenter ~* '(540|001|900)')
>
>
Unsurprising given that there is no concept of "case" with numbers.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rounak Jain | 2017-02-05 10:56:18 | alter existing table column with primary key to auto-increment |
| Previous Message | Cat | 2017-02-04 04:23:12 | Re: Trouble with IN operator |