Tom Lane píše v út 31. 03. 2009 v 13:10 -0400:
> Zdenek Kotala <zdenek.kot...@sun.com> writes:
> > The main problem what I see here is that getopt and getopt_long works
> > together. Use one from system and one ported is not good idea.
>
> Well, the expected (and pretty-well-tested) case is that your system has
> getopt but not getopt_long. I don't see any reason why using ported
> getopt_long in that case is "not good idea".
I'm looking on to POSIX and all opt* variable are specified there and
getopt_long use only what is specified. It should be OK.
> I agree that substituting getopt without substituting getopt_long is a
> tad risky, and probably hasn't been tested anyplace else previously.
It seems to me, that optind,... is same case lake optreset. I'm thinking
to add HAVE_INT_OPTIND macro (similar to HAVE_INT_OPTRESET) and use it
instead of HAVE_GETOPT_LONG in my previous patch.
Another possibility is to rewrite postgres(and pg_resetxlog) to use
getopt_long() instead of getopt().
> It may well be that we should revert to the previous state of affairs
> where we don't trust Solaris for either function.
I would like to solve it rather then revert back.
Zdenek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
