Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cbV1K-0006NP-32 for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Feb 2017 16:23:02 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cbV1J-00044f-J0 for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Feb 2017 16:23:01 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cbV1I-00044Q-RV for pgsql-hackers@postgresql.org; Wed, 08 Feb 2017 16:23:01 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cbV1G-0008Jo-9D for pgsql-hackers@postgresql.org; Wed, 08 Feb 2017 16:22:59 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id v18GMurd002581; Wed, 8 Feb 2017 11:22:56 -0500 From: Tom Lane To: Robert Haas cc: Pantelis Theodosiou , Joel Jacobson , Pg Hackers Subject: Re: Idea on how to simplify comparing two sets In-reply-to: References: Comments: In-reply-to Robert Haas message dated "Wed, 08 Feb 2017 08:40:22 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2579.1486570976.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 08 Feb 2017 11:22:56 -0500 Message-ID: <2580.1486570976@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Robert Haas writes: > On Wed, Feb 8, 2017 at 4:24 AM, Pantelis Theodosiou = 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. Yes. I think a new set-operation keyword would inevitably have to be fully reserved --- UNION, INTERSECT, and EXCEPT all are --- which means that you'd break every application that has used that word as a table, column, or function name. Generally speaking, we try very darn hard not to introduce new reserved words that are not called out as reserved in the SQL standard. (And even for those, we've sometimes made the grammar jump through hoops so as not to reserve a word that we didn't reserve previously.) regards, tom lane --=20 Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers