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.steh...@gmail.com>
wrote:

>
>
> po 28. 10. 2019 v 12:39 odesílatel Eugen Konkov <kes-...@yandex.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
>>
>>
>>
>>

Reply via email to