On Tue, Aug 28, 2012 at 2:55 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
Well, I think that when there is only one LPAD function, there is also very little chance that the results will come out differently than the user expected. I'm having a hard time seeing a bright line between those two cases. Remember, I'm not proposing that we try to guess between more alternatives than we're already trying to guess between - only that we do something other than fail outright in situations where we currently do. The changes we made in 8.3 broke a bunch of cases that were actually ambiguous. That was painful, but probably for the best. What wasn't, in my opinion, for the best was that we also broke a lot of cases - including this one - that were by no means ambiguous. In fact, I believe that every place that I had to fix my application code actually fell into the latter category: there was no actual ambiguity, but I had to go back and insert a cast anyway. -- 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