Re: Solaris getopt_long and PostgreSQL - Mailing list pgsql-hackers

From Chuck McDevitt
Subject Re: Solaris getopt_long and PostgreSQL
Date
Msg-id 2106D8DC89010842BABA5CD03FEA4061B249C99B@EXVMBX018-10.exch018.msoutlookonline.net
Whole thread Raw
In response to Re: Solaris getopt_long and PostgreSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Solaris getopt_long and PostgreSQL  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
List pgsql-hackers
Perhaps I could use the same test pg_status uses to decide PS_USE_CHANGE_ARGV and PS_USE_CLOBBER_ARGV?

Any obviously, we don't just use ours for platforms with no or broken getopt_long, since we are talking Solaris (which
hasa bug in getopt, but getopt_long works fine) 

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Tuesday, March 17, 2009 11:26 AM
> To: Chuck McDevitt
> Cc: Zdenek Kotala; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Solaris getopt_long and PostgreSQL
>
> Chuck McDevitt <cmcdevitt@greenplum.com> writes:
> > This is because MAC, BSD and GNU getopt_long permutes the arguments,
> and our getopt_long does not.
>
> AFAIK those all work by scribbling on the original argv[] array, a
> behavior that seems pretty risky from a portability standpoint.
> Since our port/ module is only going to get used on old platforms with
> no or broken getopt_long(), it needs to be pretty conservative about
> what it assumes the system environment can handle.
>
>             regards, tom lane


pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Problem with accesing Oracle from plperlu functionwhen using remote pg client.
Next
From: Tom Lane
Date:
Subject: Re: DTrace probes broken in HEAD on Solaris?