Noah Misch <noah@leadboat.com> writes:
> On Sat, Oct 25, 2014 at 09:28:27PM -0400, Tom Lane wrote:
>> I thought a bit more about this, and that idea isn't going to work, at
>> least not by itself. Right now you can do, eg, "integer IS DISTINCT
>> FROM numeric", and it works, but the way it works is that the integer
>> is promoted to numeric and we use the "numeric = numeric" operator.
>> int and numeric do not have an opfamily in common, so this case would
>> fail with the rule above.
> Is there something precluding implementation of an all-numeric-types opfamily
> that contains the existing default btree opclass operators? That wouldn't
> solve every example like this, but it would help here among other places.
That solves only the first example I came up with, not the general
problem. Another case of the same ilk is "int IS DISTINCT FROM float8",
which also works today, and which we *cannot* fix by merging the int and
float opclasses. (Equality would not be transitive in such an opfamily.)
text vs bpchar comparison is another example, and I'm sure there are more.
>> Heikki Linnakangas <hlinnakangas@vmware.com> writes:
>>> I don't think this can be solved without some additional syntax, for
>>> specifying the equality operator explicitly. I propose that we add an
>>> optional USING <operator> after the problematic expressions:
> The similar situation with IN -> =ANY is tolerable, and I could be content
> with ruleutils deparsing that way every time. That's certainly the safe fix.
That's completely not comparable, because =ANY is still valid/standard
SQL syntax. I don't see how you can justify the idea that introducing
new, nonstandard syntax for a fundamental SQL operator is better than
introducing a new operator selection rule.
Keep in mind also that IS DISTINCT FROM is just the tip of the iceberg.
There's also the shorthand CASE syntax, and probably some other cases
that I'm not recalling in my caffeine-deprived state.
regards, tom lane
