On Mon, Oct 28, 2019 at 10:07 AM Tom Lane <t...@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
