| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: operator exclusion constraints |
| Date: | 2009-11-06 19:22:31 |
| Message-ID: | 1257535351.28470.227.camel@monkey-cat.sm.truviso.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2009-11-06 at 14:00 -0500, Tom Lane wrote:
> The main advantage of the CHECK WITH syntax in my eyes was that it
> avoided the need to create a new reserved word.
It still needs the EXCLUSION keyword, though, and where does that fit
in? If I include it as unreserved, I get shift/reduce conflicts. If I
include it as a type_func_name keyword, it works.
CHECK, FOREIGN, PRIMARY, and UNIQUE are all reserved as well, which
makes sense because it looks like they conflict directly with column
names in the table definition.
Do you see a way to avoid that problem?
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-11-06 19:47:58 | WHERE CURRENT OF $n still needed? |
| Previous Message | Robert Haas | 2009-11-06 19:22:03 | Re: operator exclusion constraints |