Re: MySQL search query is not executing in Postgres DB
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Eisentraut <peter_e@gmx.net>, Greg Stark <stark@mit.edu>, Bruce Momjian <bruce@momjian.us>, Andrew Dunstan <andrew@dunslane.net>, premanand <kottiprem@gmail.com>, pgsql-hackers@postgresql.org
Date: 2012-11-25T23:46:52Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes: > On Thu, Nov 22, 2012 at 10:17 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> The argument here is basically between ease of use and ability to detect >> common programming mistakes. It's not clear to me that there is any >> principled way to make such a tradeoff, because different people can >> reasonably put different weights on those two goals. > I think that is true. But for whatever it's worth, and at the risk of > beating a horse that seems not to be dead yet in spite of the fact > that I feel I've already administered one hell of a beating, the LPAD > case is unambiguous, and therefore it is hard to see what sort of > programming mistake we are protecting users against. I think we're talking past each other here. It is unarguable that (as long as there's only one LPAD function) there is only one possible non-error interpretation. However, you are ignoring the real possibility that perhaps the situation *is* an error: maybe the user typed the wrong function name, or the wrong field name, or simply misunderstands what the function is meant to do. If it is a typo then complaining about the datatype mismatch is a good thing to do. If it is intentional, then requiring an explicit cast makes it clear to all concerned that what's wanted is to convert the non-string value to a string and then perform a string-ish operation on it. regards, tom lane