Re: MySQL search query is not executing in Postgres DB

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Greg Stark <stark@mit.edu>, Bruce Momjian <bruce@momjian.us>, Andrew Dunstan <andrew@dunslane.net>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, premanand <kottiprem@gmail.com>, pgsql-hackers@postgresql.org
Date: 2012-08-29T04:27:18Z
Lists: pgsql-hackers

Attachments

I wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> That problem is dead.

> The reason it's dead is that we killed it in 8.3.  I don't want it
> coming back to life, but I think that that will be exactly the outcome
> if we let any implicit casts to text get back into the rules for
> operator/function overloading resolution.

To put some concreteness into what so far has been a pretty hand-wavy
discussion, I experimented with the attached patch.  I'm not sure that
it exactly corresponds to what you proposed, but I think this is the
only place the consideration could be injected without a substantial
amount of code rearrangement.  This results in half a dozen regression
test failures (see second attachment), which mostly consist of
"function/operator does not exist" errors changing to "function/operator
is not unique".  I've not looked into exactly why each one happens ---
possibly the code is now finding multiple string-category matches where
before it found none.  But it definitely illustrates my point that this
would not be without surprises.

Oh, one more thing:

regression=# select lpad(42,8);
ERROR:  failed to find conversion function from integer to text

so this doesn't actually solve the problem you want to solve.
I'm not sure why that's happening, either, but evidently some
additional coercion laxity would required.

			regards, tom lane