On Mon, Oct 28, 2019 at 10:07 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I kind of like AINT ;-) ... although adding two new short,
> fully-reserved words is likely to cause push-back from people
> whose schemas get broken by that.
>
> A more practical answer might be to allow these to be abbreviated
> along the lines of
>
> x DIST y
> x NOT DIST y
>
> if we're willing to make DIST a fully reserved word.
> It's possible that we could make
>
> x IS DIST y
> x IS NOT DIST y
>
> work without fully reserving DIST, but I've not tried it.
I don't like either of these proposals much. I think DIST is not very
clear: I think a variety of things other than DISTINCT might come to
mind (distribution?) and we have no precedent for chopping off the
tail end of an English word just to save keystrokes. And I think
adding fully-reserved keywords would do far more damage than we can
justify on account of this annoyance.
> Of course neither of those ideas is as short as "==", but
> I think we should put some weight on not breaking things.
> I do not believe Robert's position that nobody will complain
> if we break extensions' use of "==" just to save some typing.
I mean, do we have to break the extensions? If we just added ==
operators that behaved like IS NOT DISTINCT FROM to each datatype, why
would anything get broken? I mean, if someone out there has a
==(int4,int4) operator, that would get broken, but what's the evidence
that any such thing exists, or that its semantics are any different
from what we're talking about?
If we added == as a magic parser shortcut for IS NOT DISTINCT FROM,
that would be more likely to break things, because it would affect
every conceivable data type. I don't think that's a great idea, but
I'd also be curious to see what evidence you have that there are
enough extensions out there of sufficient popularity that this would
be a big problem. For instance, if PostGIS uses this operator name,
that'd be good evidence that it's a real problem, but if the only
examples we can find are things that are relatively obscure, then, at
least to me, that would be different.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
