Re: Idea on how to simplify comparing two sets

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pantelis Theodosiou <ypercube(at)gmail(dot)com>, Joel Jacobson <joel(at)trustly(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Idea on how to simplify comparing two sets
Date: 2017-02-08 16:22:56
Message-ID: 2580.1486570976@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Feb 8, 2017 at 4:24 AM, Pantelis Theodosiou <ypercube(at)gmail(dot)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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Erik Nordström 2017-02-08 16:25:34 Patch: Avoid precision error in to_timestamp().
Previous Message Daniel Gustafsson 2017-02-08 16:15:35 Re: [PATCH] configure-time knob to set default ssl ciphers