Re: Proposition to use '==' as synonym for 'IS NOT DISTINCT FROM'

Would it be possible to just use `IS`, `IS NOT` instead of `IS [NOT]
DISTINCT FROM`? It's always surprised me that you can write `IS NULL`, `IS
TRUE`, etc. but they're all special-cased. I could see it introducing a
parsing ambiguity, but it doesn't seem impossible to resolve?

On Mon, Oct 28, 2019 at 12:49 PM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
wrote:

>
>
> po 28. 10. 2019 v 12:39 odesílatel Eugen Konkov <kes-kes(at)yandex(dot)ru>
> napsal:
>
>> > x IS NOT DISTINCT FROM y
>>
>> > I'm vaguely imagining
>>
>> > x = {magic} y
>>
>> > where unlike Eugen's suggestion, "=" is the real name of the underlying
>> > comparison operator. For dump/restore this could be spelled verbosely
>> > as
>>
>> > x OPERATOR(someplace.=) {magic} y
>>
>> > The hard part is to figure out some {magic} annotation that is both
>> > short and unambiguous. We have to cover the IS DISTINCT variant, too.
>>
>> I am from Perl world. There are == and != operators.
>> Here short snippet of code:
>>
>> my $x = undef;
>> my $y = 'some value';
>> my $z = undef;
>> $x == $y; # FALSE
>> $x == $z; # TRUE
>> $x != $y ; # TRUE
>> $x != $z; # FALSE
>>
>>
>> > x OPERATOR(someplace.=) {magic} y
>> If we should follow this form, then IS DISTINCT should be written as:
>> x =! y
>> This looks unusual, because JavaScript also follow != form. so I hope
>> it will be easy to detect/implement != form, which I used to read as:
>> negate the result of comparison
>>
>>
>>
>> Can we supply additional parameters to OPERATOR via double
>> parentheses( double parentheses is another crazy idea)?
>> x =(( 'NULL' )) y
>>
>
> It's looks much more terrible than original IS DISTINCT FROM
>
>
>> or
>>
>> x OPERATOR(someplace.=, magic ) y
>> which will be internally converted( I suppose ) to OPERATOR(
>> someplace.=, x, y, magic )
>>
>
> I don't think so benefit of this is too valuable against possible problems.
>
> MySQL has special operator <=>, so if we implement some, then we should to
> implement this. But better do nothing. I don't see significant benefit of
> this against costs.
>
> Pavel
>
>>
>> --
>> Best regards,
>> Eugen Konkov
>>
>>
>>
>>