Re: [HACKERS] Our getopt_long() doesn't do abbreviations or NLS

2005-02-02 Thread Peter Eisentraut
Tom Lane wrote: > I seem to recall that there was some special consideration for files > that would conditionally show up in multiple executables. Or were > you going to fix that by having just one .mo file for all the > clients? The current method is to explicitly register the source file in eac

Re: [HACKERS] Our getopt_long() doesn't do abbreviations or NLS

2005-02-01 Thread Tom Lane
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Should it be gettext'ified? > Probably. I seem to recall that there was some special consideration for files that would conditionally show up in multiple executables. Or were you going to fix that by having just one .mo file for a

Re: [HACKERS] Our getopt_long() doesn't do abbreviations or NLS

2005-02-01 Thread Peter Eisentraut
Tom Lane wrote: > I just noticed that our port/getopt_long.c substitute implementation > does not accept abbreviated names for long options: That is known, but since we don't advertise that feature, it's not a problem. > Barring objections, I'm going to modify our version to allow unique > abbre

[HACKERS] Our getopt_long() doesn't do abbreviations or NLS

2005-01-31 Thread Tom Lane
I just noticed that our port/getopt_long.c substitute implementation does not accept abbreviated names for long options: $ pg_dump --username tgl regression ... works ... $ pg_dump --user tgl regression pg_dump: illegal option -- user Try "pg_dump --help" for more information. $ The GNU implement