On Thu, Sep 8, 2016 at 5:21 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Stephen Frost <sfr...@snowman.net> writes: >> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: >>> Can't you keep those words as Sconst or something (DefElems?) until the >>> execution phase, so that they don't need to be keywords at all? > >> Seems like we could do that, though I'm not convinced that it really >> gains us all that much. These are only unreserved keywords, of course, >> so they don't impact users the way reserved keywords (of any kind) can. >> While there may be some places where we use a string to represent a set >> of defined options, I don't believe that's typical > > -1 for having to write them as string literals; but I think what Alvaro > really means is to arrange for the words to just be identifiers in the > grammar, which you strcmp against at execution. See for example > reloption_list. (Whether you use DefElem as the internal representation > is a minor detail, though it might help for making the parsetree > copyObject-friendly.) > > vacuum_option_elem shows another way to avoid making a word into a > keyword, although to me that one is more of an antipattern; it'd be better > to leave the strcmp to execution, since there's so much other code that > does things that way.
There are other cases like that, too, e.g. AlterOptRoleElem; I don't think it's a bad pattern. Regardless of the specifics, I do think that it would be better not to bloat the keyword table with things that don't really need to be keywords. -- 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