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

On Fri, Dec 14, 2012 at 2:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> ...  In more
>> than ten years of working with PostgreSQL, I've never encountered
>> where the restriction at issue here prevented a bug.  It's only
>> annoyed me and broken my application code (when moving from PostgreSQL
>> 8.2 to PostgreSQL 8.3, never mind any other database!).
>
> There are quite a few examples in our archives of application bugs that
> would have been prevented, or later were prevented, by the 8.3 changes
> that reduced the system's willingness to apply implicit casts to text.
> I recall for instance cases where people got wrong/unexpected answers
> because the system was sorting what-they-thought-were-timestamp values
> textually.
>
> So I find such sweeping claims to be demonstrably false, and I'm
> suspicious of behavioral changes that are proposed with such arguments
> backing them.

I think you're mixing apples and oranges.  The whole point of the
patch on the table - which, if you recall, was designed originally by
you and merely implemented by me - was to change the behavior only in
the cases where there's only one function with the appropriate name
and argument count.  The ambiguous cases that 8.3+ helpfully prevent
are those where overloading is in use and the choice of which function
to call is somewhat arbitrary and perhaps incorrectly-foreseen by the
user.  Those changes also have the side-effect of preventing a
straightforward function call from working without casts even in cases
where no overloading is in use - and making that case work is
completely different from making the ambiguous case arbitrarily pick
one of the available answers.

> Oh, I don't think we're ignoring the problem; people beat us up about it
> too often for that.  But we need to pay attention to error detection not
> only ease-of-use, so it's hard to be sure what's a net improvement.

Well, that's not how the dynamic of this thread reads to me.  There
seems to be massive opposition - including from you - to allowing
unambiguous function calls to resolve without casts, at least as a
categorical matter, and maybe even in the specific cases that users
most frequently care about.  I simply disagree with the contention
that there's a value in making people cast to text when the target
function is not overloaded.  Maybe there's some world where it's
uncommon to want to pass the text representation of a non-text value
to a non-overloaded function that accepts text, and therefore forcing
a cast upon the user to warn them "here be dragons" is warranted, but
I don't live in it.  When the function IS overloaded, well, that's a
completely different situation.  I've written enough C++ over the
years to understand what happens when you try too hard to be clever
with tiebreak rules.  But that's not got much to do with the question
of whether the only candidate to put in an appearance can be declared
the winner.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company