Re: MySQL search query is not executing in Postgres DB - Mailing list pgsql-hackers

From Tom Lane
Subject Re: MySQL search query is not executing in Postgres DB
Date
Msg-id 6825.1346180156@sss.pgh.pa.us
Whole thread Raw
In response to Re: MySQL search query is not executing in Postgres DB  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: MySQL search query is not executing in Postgres DB
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Aug 28, 2012 at 1:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> There still won't be a candidate for that one, unless you're proposing
>> to allow explicit-only coercions to be applied implicitly.

> [ not so, see kluge in find_coercion_pathway() ]

Oh, I'd forgotten that worked that way.  Frankly, that makes me quite a
bit more concerned about this proposal than I was before.  I do *not*
want to re-introduce silent cross-category casts to text, not even if
there's no other way to match the function/operator.  I think that hack
was/is tolerable for actual assignment to a table column, because there
is very little chance that the semantics of such an assignment will come
out differently than the user expected.  This is not the case when
you're matching to potentially overloaded functions or operators,
though.  If we go down this route we're going to find ourselves back in
the badlands of timestamps sometimes being compared as though they were
strings, and all the other sillinesses that we got rid of in 8.3.  I got
beat up enough already for taking those toys away from people; I'm not
looking forward to having to have another round of it in the future.

I could see doing what you suggest as long as we exclude the
automatic-coerce-via-IO case.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: SP-GiST micro-optimizations
Next
From: Bruce Momjian
Date:
Subject: Re: FATAL: bogus data in lock file "postmaster.pid": ""