On Mon, Aug 25, 2014 at 1:35 AM, Andrew Gierth <and...@tao11.riddles.org.uk> wrote: > If you look at the latest patch post, there's a small patch in it that > does nothing but unreserve the keywords and fix ruleutils to make > deparse/parse work. The required fix to ruleutils is an example of > violating your "four kinds of keywords" principle, but quoting > keywords still works.
I think it would be intolerable to lose the ability to quote keywords. That could easily create situations where there's no reasonable way to dump an older database in such a fashion that it can be reloaded into a newer database. So it's good that you avoided that. The "four kinds of keywords" principle is obviously much less absolute. We've talked before about introducing additional categories of keywords, and that might be a good thing to do for one reason or another. But I think it's not good to do it in a highly idiosyncratic way: I previously proposed reserving concurrently only when it follows CREATE INDEX, and not in any other context, but Tom argued that it had to become a type_func_name_keyword since users would be confused to find that concurrently (but not any other keyword) needed quoting there. In retrospect, I tend to think he probably had it right. There is a good amount of third-party software out there that tries to be smart about quoting PostgreSQL keywords - for example, pgAdmin has code for that, or did last I looked - so by making things more complicated, we run the risk not only of bugs in our own software but also bugs in other people's software, as well as user confusion. So I still think the right solution is probably to reserve CUBE across the board, and not just in the narrowest context that we can get away with. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
