Re: Solaris getopt_long and PostgreSQL

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-31 17:10:56
Message-ID: 22853.1238519456@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:
> 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 agree that substituting getopt without substituting getopt_long is a
tad risky, and probably hasn't been tested anyplace else previously.
It may well be that we should revert to the previous state of affairs
where we don't trust Solaris for either function.

> I think best solution is to port new BSD version into postgreSQL and
> use both function from libc version or ported versin.

I'm not sure which part of "no" you didn't understand. Changing the
contents of argv[] is going to be system-specific and there is no reason
to believe that a BSD implementation will work everywhere.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2009-03-31 17:14:20 Re: can't load plpython
Previous Message Greg Stark 2009-03-31 17:06:03 Re: string_to_array with empty input