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
