Tom Lane píše v ne 05. 04. 2009 v 17:44 -0400:
> Zdenek Kotala writes:
> > Zdenek Kotala píše v út 31. 03. 2009 v 21:25 +0200:
> >> Another possibility is to rewrite postgres(and pg_resetxlog) to use
> >> getopt_long() instead of getopt().
>
> > Attached patch rewrites postgres to use getopt_lon
Zdenek Kotala writes:
> Zdenek Kotala pÃÅ¡e v út 31. 03. 2009 v 21:25 +0200:
>> Another possibility is to rewrite postgres(and pg_resetxlog) to use
>> getopt_long() instead of getopt().
> Attached patch rewrites postgres to use getopt_long instead of getopt.
Actually, I fooled around with it l
Zdenek Kotala píše v út 31. 03. 2009 v 21:25 +0200:
> Another possibility is to rewrite postgres(and pg_resetxlog) to use
> getopt_long() instead of getopt().
Attached patch rewrites postgres to use getopt_long instead of getopt.
Patch also removes configure part for Solaris related to getopt.
Tom Lane píše v út 31. 03. 2009 v 13:10 -0400:
> Zdenek Kotala 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
> geto
Zdenek Kotala 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 po
Dne 31.03.09 18:21, Tom Lane napsal(a):
Zdenek Kotala writes:
Yeah correct, I overlooked that optreset is also defined as a extern.
There is updated patch.
On looking at this I still can't see how it's not broken. You are
effectively assuming that getopt_long.c must define those variables.
Zdenek Kotala writes:
> Yeah correct, I overlooked that optreset is also defined as a extern.
> There is updated patch.
On looking at this I still can't see how it's not broken. You are
effectively assuming that getopt_long.c must define those variables.
But surely getopt_long.c should be assum
Dne 31.03.09 04:55, Tom Lane napsal(a):
Zdenek Kotala writes:
I attached a fix. Only problem what I see there is getopt_long.h which
contains
I'm more concerned about the "static int optreset", which is 100%
guaranteed to break things.
Yeah correct, I overlooked that optreset is also defin
Zdenek Kotala writes:
> I attached a fix. Only problem what I see there is getopt_long.h which
> contains
I'm more concerned about the "static int optreset", which is 100%
guaranteed to break things.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hacke
Tom Lane píše v so 28. 03. 2009 v 14:36 -0400:
> Apparently the system version of getopt_long is broken on Solaris 11.
> My patience for this grows short.
It is not problem with getopt_long itself, but with symbol overriding.
getopt_long uses optind and so on from libc, but e.g. initdb takes
opt
Tom Lane píše v so 28. 03. 2009 v 14:36 -0400:
> I wrote:
> > 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
I wrote:
> 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
>
Zdenek Kotala 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 i
On Tuesday 17 March 2009 20:02:14 Tom Lane wrote:
> Zdenek Kotala writes:
> > [ use Solaris' version of getopt_long ]
>
> The reason not to do that was discussed in this thread:
>
> http://archives.postgresql.org//pgsql-patches/2008-02/msg00075.php
That discussion was about option parsing in post
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. It is Solaris' getopt exte
Original Message-
> From: Tom Lane [mailto:t...@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 writes:
> &g
Chuck McDevitt 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
t; To: Zdenek Kotala
> Cc: Chuck McDevitt; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Solaris getopt_long and PostgreSQL
>
> Zdenek Kotala writes:
> > [ use Solaris' version of getopt_long ]
>
> The reason not to do that was discussed in this thread:
>
>
Zdenek Kotala writes:
> [ use Solaris' version of getopt_long ]
The reason not to do that was discussed in this thread:
http://archives.postgresql.org//pgsql-patches/2008-02/msg00075.php
While Chuck is certainly free to build his local copy however he wants,
I don't think we're going to revert
Dne 17.03.09 17:24, Zdenek Kotala napsal(a):
Dne 17.03.09 17:13, Zdenek Kotala napsal(a):
I don’t know if I should revert that change, or port netBSD
getopt_long and replace the PostgreSQL one with that.
getopt_long is OK. Problem is getopt. getopt in core is currently
taken from *BSD but it
Dne 17.03.09 17:13, Zdenek Kotala napsal(a):
I don’t know if I should revert that change, or port netBSD
getopt_long and replace the PostgreSQL one with that.
getopt_long is OK. Problem is getopt. getopt in core is currently taken
from *BSD but it could be updated.
One possible solution sho
Dne 17.03.09 16:38, Chuck McDevitt napsal(a):
About a year ago, you talked to the PostgreSQL people about some problem
with Solaris getopt_long, and they changed the build to use the internal
getopt_long instead of the Solaris one?
The problem was with getopt which is works little bit differ
About a year ago, you talked to the PostgreSQL people about some problem with
Solaris getopt_long, and they changed the build to use the internal getopt_long
instead of the Solaris one?
What was the problem with Solaris getopt_long? Does the problem still exist in
Solaris 10?
My users are unh
23 matches
Mail list logo
