On Fri, Dec 13, 2013 at 4:06 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > BTW, so far as the syntax goes, I'm quite distressed by having to make > REJECTS into a fully-reserved word. It's not reserved according to the > standard, and it seems pretty likely to be something that apps might be > using as a table or column name.
I've been looking at this, but I'm having a hard time figuring out a way to eliminate shift/reduce conflicts while not maintaining REJECTS as a fully reserved keyword - I'm pretty sure it's impossible with an LALR parser. I'm not totally enamored with the exact syntax proposed -- I appreciate the flexibility on the one hand, but on the other hand I suppose that REJECTS could just as easily be any number of other words. One possible compromise would be to use a synonym that is not imagined to be in use very widely, although I looked up "reject" in a thesaurus and didn't feel too great about that idea afterwards. Another idea would be to have a REJECTING keyword, as the sort of complement of RETURNING (currently you can still ask for RETURNING, without REJECTS but with ON DUPLICATE KEY LOCK FOR UPDATE if that happens to make sense). I think that would work fine, and might actually be more elegant. Now, REJECTING will probably have to be a reserved keyword, but that seems less problematic, particularly as RETURNING is itself a reserved keyword not described by the standard. In my opinion REJECTING would reinforce the notion of projecting the complement of what RETURNING would project in the same context. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers