Re: Solaris getopt_long and PostgreSQL
От | Zdenek Kotala |
---|---|
Тема | Re: Solaris getopt_long and PostgreSQL |
Дата | |
Msg-id | 1238999336.1387.7.camel@localhost обсуждение исходный текст |
Ответ на | Re: Solaris getopt_long and PostgreSQL (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane píše v ne 05. 04. 2009 v 17:44 -0400: > Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes: > > Zdenek Kotala píše v út 31. 03. 2009 v 21:25 +0200: > >> Another possibility is to rewrite postgres(and pg_resetxlog) to use > >> getopt_long() instead of getopt(). > > > Attached patch rewrites postgres to use getopt_long instead of getopt. > > Actually, I fooled around with it last night and seem to have fixed it > (buildfarm is all green today) by the expedient of not defining our own > optind etc. variables if the system supplies them. So that seemed like > a clean fix to me --- the old handling of optreset in particular was a > huge kluge, whereas it's clear how this code is supposed to work. Yeah, everything is green today. Thanks. Is it possible to backport it at least to 8.3? > I don't think we need to mess around with changing our option parsing > logic, especially not to the extent that you propose here. When previous solution works well on all platforms there is no reason to use getopt_long. Thanks Zdenek
В списке pgsql-hackers по дате отправления: