Robert Haas <robertmhaas@gmail.com> writes:
> I continue to be of the opinion that our behavior in this area is
> bone-headed. It's reasonable to reject integer = character varying on
> the basis that we don't know whether integer or character varying
> comparison semantics are wanted, and the two might give different
> answers (think: leading zeroes), so we'd better ask the user to
> clarify. But '1' LIKE 1 is not ambiguous; there is only one
> plausible meaning for that, and we ought to adopt it, per the patch I
> proposed previously. Rejecting SQL that other systems happily accept
> is unhelpful and unfriendly and it is costing us users and mind-share.
I don't agree with this opinion. '1' + '2' might be claimed to have
only one plausible meaning as well, but that doesn't mean that we should
accept it. There is a very fundamental distinction between numbers and
strings, and we'd do our users no service by pretending there isn't.
What's more, your argument for this essentially rests on the assumption
that LIKE represents only one possible operator choice, which is already
false today (see \do ~~) and might be even more false in future.
regards, tom lane
