On Fri, Dec 14, 2012 at 2:11 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
