Tom Lane wrote:
> I don't offhand see anything else I'd consider weakening the casting
> rules for. If anyone else is interested, I took
...
> substring(text,integer) |
> substring(text,integer,integer) |
> substring(text,text) |
> substring(text,text,text) |
> texticlike(text,text) | ~~*
> texticnlike(text,text) | !~~*
> texticregexeq(text,text) | ~*
> texticregexne(text,text) | !~*
> textlike(text,text) | ~~
> textnlike(text,text) | !~~
> textregexeq(text,text) | ~
> textregexne(text,text) | !~
> upper(text) |
>
>
> Thoughts?
In one of our applications, we have some "numbers" (e.g. product
numbers) that have meaning attached to individual digits. Product
numbers usually contain letters, too, but for historical reasons they do
not in this application. So we put them into integer columns for
efficiency. We still want to run queries like product_no LIKE '51%' on them.
Well, for the application, I don't see much of a problem here. This will
probably cost 3-5 lines of code in the whole application. It will just
cause some inconvenience when working with psql interactively.
And I have not yet seen another DBMS that does not accept almost any
input type for the typical string operations such as substring or LIKE.
It feels a little bit strange that I will have to do all that
typecasting now.
Just my $0.02.
Best Regards
Michael Paesold
