On Wed, Aug 29, 2012 at 06:39:37PM -0400, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On the more general issue, I continue to see minimal risk of harm > > in allowing things like LPAD() to implicitly cast the first > > argument to text. > > Well, I see your point about LPAD(), but the problem is how to tell > the difference between a harmless cast omission and an actual > mistake that the user will be very grateful if we point out. If we > allow implicit casts to text in the general case in > function/operator calls, we are definitely going to re-introduce a > lot of room for mistakes. > > Upthread you were complaining about how we'd reject calls even when > there was only one possible interpretation. I wonder whether > there'd be any value in taking that literally: that is, allow use of > assignment rules when there is, in fact, exactly one function with > the right number of parameters visible in the search path.
+1 for this. > The main downside I can see is that code that used to work is likely > to stop working as soon as someone creates a potential overloading > situation. Worse, the error message could be pretty confusing, > since if you had been successfully calling f(smallint) with f(42), > you'd get "f(integer) does not exist", not something like "f() is > ambiguous", after adding f(float8) to the mix. This seems related > to the confusing changes in regression test cases that I got in my > experiments yesterday. This may be sufficient reason to reject the > idea, since the very last thing we need in this area is any > degradation in the relevance of the error messages. With the ANY* parameters introduced in the past few versions, there's a lot less incentive to create this problem. The trick here is documenting the ANY* parameters in enough places to make sure that incentive is reduced. Cheers, David. -- David Fetter <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers