Re: pg_dump.options.diff

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Serguei Mokhov" <mokhov(at)cs(dot)concordia(dot)ca>
Cc: "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>
Subject: Re: pg_dump.options.diff
Date: 2003-01-02 06:34:23
Message-ID: 18064.1041489263@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

"Serguei Mokhov" <mokhov(at)cs(dot)concordia(dot)ca> writes:
> Attached is an attempt to eliminate duplicate pg_dump
> option descriptions, and have a single description for both
> short and long options. For me, as for a translator, this
> eliminates the need to maintain the two, exactly same, sets of
> 24 sentences.

Offhand, this cure strikes me as much worse than the disease. You've
converted code which was understandable, if somewhat repetitious, into
code that can be understood by neither programmers nor translators.
The text strings have been broken into fragments that don't make any
sense individually --- which probably creates translating problems,
as well as opportunities for programmer error.

I see your complaint, but this doesn't seem like a good way to fix it.

Perhaps it would work better to do something like

#ifdef HAVE_GETOPT_LONG
char* f_option = _("-f, --file=FILENAME ");
... etc ...
#else /* not HAVE_GETOPT_LONG */
char* f_option = _("-f FILENAME ");
... etc ...
#endif /* not HAVE_GETOPT_LONG */

printf(_(" %s output file name\n"), f_option);
... etc ...

That seems to reduce the amount of duplication without breaking things
up into chunks that aren't independent concepts.

However, I'm not convinced that the above is better than what we have
--- it's really not obvious that the above is more maintainable than

#ifdef HAVE_GETOPT_LONG
printf(_(" -f, --file=FILENAME output file name\n"));
#else /* not HAVE_GETOPT_LONG */
printf(_(" -f FILENAME output file name\n"));
#endif /* not HAVE_GETOPT_LONG */

There are worse things than a little repetitiveness, and creating
the opportunity to mismatch a flag with its description may well
be one of them.

Comments? Can anyone do better?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2003-01-02 06:43:15 Re: Cast your vote ...
Previous Message Marc G. Fournier 2003-01-02 06:24:34 Cast your vote ...

Browse pgsql-patches by date

  From Date Subject
Next Message Serguei Mokhov 2003-01-02 06:44:21 Re: pg_dump.options.diff
Previous Message Serguei Mokhov 2003-01-02 06:16:58 pg_dump.options.diff