Re: Differences in WHERE clause of SELECT

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Differences in WHERE clause of SELECT
Date: 2013-07-16 16:05:00
Message-ID: 12805.1373990700@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2013-07-16 16:41:25 Re: checking variadic "any" argument in parser - should be array
Previous Message Robert Haas 2013-07-16 15:57:19 Re: SSL renegotiation