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
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 |