Re: MySQL search query is not executing in Postgres DB
От | David Fetter |
---|---|
Тема | Re: MySQL search query is not executing in Postgres DB |
Дата | |
Msg-id | 20120830130639.GA4314@fetter.org обсуждение исходный текст |
Ответ на | Re: MySQL search query is not executing in Postgres DB (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Wed, Aug 29, 2012 at 06:39:37PM -0400, Tom Lane wrote: > Robert Haas <robertmhaas@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 <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@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
В списке pgsql-hackers по дате отправления: