Re: Solaris getopt_long and PostgreSQL

Tom Lane píše v út 31. 03. 2009 v 13:10 -0400:
> Zdenek Kotala <Zdenek.Kotala@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