Skip site navigation (1) Skip section navigation (2)

Re: Solaris getopt_long and PostgreSQL

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Chuck McDevitt <cmcdevitt(at)greenplum(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Solaris getopt_long and PostgreSQL
Date: 2009-03-31 19:25:18
Message-ID: 1238527518.1429.12.camel@localhost (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane píše v út 31. 03. 2009 v 13:10 -0400:
> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)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



In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-03-31 19:27:38
Subject: Re: [GENERAL] pgstattuple triggered checkpoint failure and database outage?
Previous:From: Heikki LinnakangasDate: 2009-03-31 19:18:42
Subject: Re: More message encoding woes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group