On Tue, May 2, 2017 at 3:02 PM, Petr Jelinek
<petr.jelinek@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
