Re: MySQL search query is not executing in Postgres DB
От | Tom Lane |
---|---|
Тема | Re: MySQL search query is not executing in Postgres DB |
Дата | |
Msg-id | 6825.1346180156@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: MySQL search query is not executing in Postgres DB (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: MySQL search query is not executing in Postgres DB
|
Список | 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 по дате отправления: