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

From Tom Lane
Subject Re: Solaris getopt_long and PostgreSQL
Date
Msg-id 3994.1238184078@sss.pgh.pa.us
Whole thread Raw
In response to Re: Solaris getopt_long and PostgreSQL  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Responses Re: Solaris getopt_long and PostgreSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> Dne 17.03.09 19:48, Chuck McDevitt napsal(a):
>> Any obviously, we don't just use ours for platforms with no or broken getopt_long, 
>> since we are talking Solaris (which has a bug in getopt, but 
>> getopt_long works fine)

> Just for clarification:

> It is not bug in Solaris.

Well, "bug" in the sense that it doesn't do what we want it to.

After reviewing this thread and the one that led up to the 8.3 behavior,
it seems clear that we failed to draw a distinction between getopt and
getopt_long when we should have.  We don't like Solaris' getopt but
there seems no reason not to use Solaris' getopt_long.  So Zdenek's
suggestion to change configure seems the correct fix, and I've done
that.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Any reason not to return row_count in cursor of plpgsql?
Next
From: Michael Renner
Date:
Subject: Documentation Update: Document pg_start_backup checkpoint behavior