"Prabakaran, Vaishnavi" <vaishna...@fast.au.fujitsu.com> writes:
> The specific use case which I am interested in is
> " Numeric LIKE Pattern_string ".
> I'm willing to attempt a patch to support the specific use case above by
> adding implicit casts, without modifying the entire casting rules.
> Is this something that is likely to be included in the code ?
No, especially not if you do it by adding implicit casts. That would
have unfortunate side-effects in all sorts of contexts.
If you're dead set on having this sort of behavior, you can do it today
with a custom operator, for instance:
regression=# select 1.4 like 'foo';
ERROR: operator does not exist: numeric ~~ unknown
LINE 1: select 1.4 like 'foo';
^
HINT: No operator matches the given name and argument type(s). You might need
to add explicit type casts.
regression=# create function numericlike(numeric, text) returns bool as
regression-# 'select $1::text like $2' language sql;
CREATE FUNCTION
regression=# create operator ~~ (leftarg = numeric, rightarg = text,
regression(# procedure = numericlike);
CREATE OPERATOR
regression=# select 1.4 like 'foo';
?column?
----------
f
(1 row)
I'd suggest doing that rather than making changes that are likely to
have side-effects on behavior entirely unrelated to LIKE. In addition,
you won't have to sell the community on whether this behavior is
actually a good idea.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
