On Nov 12, 2007, at 10:18 AM, Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
>> On Mon, Nov 12, 2007 at 02:46:50PM +0100, Karsten Hilbert wrote:
>>> It surely makes sense - in your environment - but it's not
>>> the only interpretation so PG tries to be impartial and
>>> makes both of us say clearly what we want.
>
>> If people want it they can add the automatic cast back in, it just
>> isn't dfault anymore.
>
> I wouldn't recommend that, as it'd re-open all the gotchas that we
> took
> out the implicit cast to prevent.
>
> However, if you want the behavior for LIKE only, you can make an
> operator:
>
> regression=# select 84 like '8%';
> ERROR: operator does not exist: integer ~~ unknown
> LINE 1: select 84 like '8%';
> ^
> HINT: No operator matches the given name and argument type(s). You
> might need to add explicit type casts.
> regression=# create function anylike(anyelement, text) returns bool
> as $$
> regression$# select $1::text like $2
> regression$# $$ language sql;
> CREATE FUNCTION
> regression=# create operator ~~ ( procedure = anylike,
> regression(# leftarg = anyelement, rightarg = text );
> CREATE OPERATOR
> regression=# select 84 like '8%';
> ?column?
> ----------
> t
> (1 row)
Does this change in implicit conversions also apply to what I've
previously seen recommended on the lists wrt filtering dates? i.e
WHERE date_field LIKE '2007-11-12%'? Just curious...
Erik Jones
Software Developer | Emma®
erik@myemma.com
800.595.4401 or 615.292.5888
615.292.0777 (fax)
Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com
