use of '=' in long options documentation

On tis, 2011-03-08 at 22:32 -0500, Bruce Momjian wrote:

Looking at our ref pages, I see some manual pages specify long options
that take arguments using '=', e.g. initdb.sgml:

--long-opt=opt

and some do not, e.g. pg_dump.sgml:

--long-opt opt

So, which should we use, for consistency?

Using = is more common usage, I think.

Peter Eisentraut wrote:

On tis, 2011-03-08 at 22:32 -0500, Bruce Momjian wrote:

Looking at our ref pages, I see some manual pages specify long options
that take arguments using '=', e.g. initdb.sgml:

--long-opt=opt

and some do not, e.g. pg_dump.sgml:

--long-opt opt

So, which should we use, for consistency?

Using = is more common usage, I think.

Yeah! Someone chimed in with a vote! I will update the docs, but not
adjust any summary that has a space after the equals, e.g. initdb.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Bruce Momjian <bruce@momjian.us> wrote:

Peter Eisentraut wrote:

On tis, 2011-03-08 at 22:32 -0500, Bruce Momjian wrote:

Looking at our ref pages, I see some manual pages specify long
options that take arguments using '=', e.g. initdb.sgml:

--long-opt=opt

and some do not, e.g. pg_dump.sgml:

--long-opt opt

So, which should we use, for consistency?

Using = is more common usage, I think.

Yeah! Someone chimed in with a vote! I will update the docs, but
not adjust any summary that has a space after the equals, e.g.
initdb.

I agree that using = is more common; but also that anything
suggesting that a space after the = should be avoided. I think it's
preferable to show the = when possible without misleading, and omit
it when it would mislead. Accuracy should trump consistency here
IMO. I think it's OK to omit in summary and show in detail.

-Kevin

Kevin Grittner wrote:

Bruce Momjian <bruce@momjian.us> wrote:

Peter Eisentraut wrote:

On tis, 2011-03-08 at 22:32 -0500, Bruce Momjian wrote:

Looking at our ref pages, I see some manual pages specify long
options that take arguments using '=', e.g. initdb.sgml:

--long-opt=opt

and some do not, e.g. pg_dump.sgml:

--long-opt opt

So, which should we use, for consistency?

Using = is more common usage, I think.

Yeah! Someone chimed in with a vote! I will update the docs, but
not adjust any summary that has a space after the equals, e.g.
initdb.

I agree that using = is more common; but also that anything
suggesting that a space after the = should be avoided. I think it's
preferable to show the = when possible without misleading, and omit
it when it would mislead. Accuracy should trump consistency here
IMO. I think it's OK to omit in summary and show in detail.

OK, agreed. I am working on a patch and will post it for review.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Applied.

---------------------------------------------------------------------------

Bruce Momjian wrote:

Kevin Grittner wrote:

Bruce Momjian <bruce@momjian.us> wrote:

Peter Eisentraut wrote:

On tis, 2011-03-08 at 22:32 -0500, Bruce Momjian wrote:

Looking at our ref pages, I see some manual pages specify long
options that take arguments using '=', e.g. initdb.sgml:

--long-opt=opt

and some do not, e.g. pg_dump.sgml:

--long-opt opt

So, which should we use, for consistency?

Using = is more common usage, I think.

Yeah! Someone chimed in with a vote! I will update the docs, but
not adjust any summary that has a space after the equals, e.g.
initdb.

I agree that using = is more common; but also that anything
suggesting that a space after the = should be avoided. I think it's
preferable to show the = when possible without misleading, and omit
it when it would mislead. Accuracy should trump consistency here
IMO. I think it's OK to omit in summary and show in detail.

OK, agreed. I am working on a patch and will post it for review.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +