On Tue, May 2, 2017 at 3:02 PM, Petr Jelinek <petr.jeli...@2ndquadrant.com> wrote: > That sounds okay. I know PeterE didn't like the lower case and > underscore separated words for options in the original patch, so I'd > like to hear his opinion on this. I am not sure how much advantage is > there in removing the '=' in between the key and value. That's the main > difference between generic options and definitions (well and definitions > can have 2 words for key, but that's something I have added anyway), I > don't really understand why we have both and use one for some commends > and the other for others btw.
I don't care all *that* much about the equals sign, although I think it's marginally more elegant without it, and VACUUM, EXPLAIN, and COPY all do it that way. But I think allowing two-word names is just a pile of parser nastiness that we'd be far better off without. If you use the same syntax as VACUUM, EXPLAIN, and COPY, all options are a single identifier. If it's got to be multiple words, they can be separated by underscores. But with what you've got right now, it's sometimes one identifier even when it's two words, and sometimes two identifiers. When it's three words, it's two identifiers, with two of them concatenated. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers