| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
| 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-27 20:01:18 |
| Message-ID: | 3994.1238184078@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Renner | 2009-03-27 20:12:41 | Documentation Update: Document pg_start_backup checkpoint behavior |
| Previous Message | Tom Lane | 2009-03-27 19:04:08 | Re: Any reason not to return row_count in cursor of plpgsql? |