On Wed, Feb 8, 2017 at 4:24 AM, Pantelis Theodosiou <yperc...@gmail.com> wrote: > I'm not advocating it but I don't see how introducing new SQL keywords > breaks backwards compatibility.
It does at least a little bit. This starts failing: select 1 new_keyword form blah; (now you have to insert AS or quote the keyword) If the new keyword is partially or fully reserved, then anybody who is using that column in a now-impermissible way has to change names of conflicting tables, columns, functions, etc. But of course we do add keywords in every release, where it's warranted by the value of the new feature. I think the problem for this proposed feature is not that adding new keywords is a completely insane thing to do but that (1) there are lots of other good ways to do more or less what is being requested with this new syntax, so it's not clear that we need a new one and (2) there are cases where it might be ambiguous which meaning of IS NOT DISTINCT FROM is met. Joel's answer to #2 is to just prefer the existing meaning wherever it's possible to assign that meaning and use the new meaning only in cases where the existing meaning is impossible, but (2a) if you tried to code it up, you'd probably find that it's quite difficult to make bison generate a grammar that works that way, because bison isn't designed around the idea of giving things a meaning only if they don't already have one and (2b) apparently ambiguities can be confusing to users even if they've been eliminated in the formal grammar. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
