Re: [HACKERS] pg_dump --help
От | Karel Zak - Zakkr |
---|---|
Тема | Re: [HACKERS] pg_dump --help |
Дата | |
Msg-id | Pine.LNX.3.96.991216131903.10164A-100000@ara.zf.jcu.cz обсуждение исходный текст |
Ответ на | Re: [HACKERS] pg_dump --help (Peter Eisentraut <e99re41@DoCS.UU.SE>) |
Список | pgsql-hackers |
On Thu, 16 Dec 1999, Peter Eisentraut wrote: > On Wed, 15 Dec 1999, Karel Zak - Zakkr wrote: > > > $ pg_dump --help > > /usr/lib/postgresql/bin/pg_dump: invalid option -- - > > > > hmm ? > > > > Prepare anyone long options for pg_dump, pg_passwd, pg_version ? > > If not, I make it, current state is disgraceful. Hi, > Only GNU (Linux) systems support long options. What you consider > disgraceful is normal behavior on the majority of platforms. Yes, I know this (it is not first program, which I hacking :-), IMHO is good resolution (?) add getopt_long() to str/utils and use it for non-GNU (non getopt_long) platforms, or not? > I put in long options into psql and into the wrapper scripts (under some > protests). But I agree that we should if at all only provide them, not > advertise them, since it's going to be a support nightmare. I saw/use your current psql (great!). Plan you add long option to usage() output? If yes, will good make identical output format for all pg_ routines (nice is example 'mc --help' styl). > If you plan on doing this, please look there and use the same options > whereever possible. I have been trying to establish some consistent > options naming across client applications. Also check out how psql copes > with systems where there are no long options available. Yes, I agree and I use your options. > Meanwhile I have been getting closer to resolving to scratch pg_dump and > write a new one for 7.1, so whatever you do now might not live long. :( Hmm.. :-(, but I not worry, it is only small work for me and you can use this options (and code) for your 7.1 version. Karel
В списке pgsql-hackers по дате отправления: