Horton

Re: Complier warnings on mingw gcc 4.5.0

Andrew Dunstan <andrew@dunslane.net>

View thread
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@commandprompt.com>, Itagaki Takahiro <itagaki.takahiro@gmail.com>, Hiroshi Inoue <inoue@tpf.co.jp>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2010-12-15T16:27:46Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Make the win32 putenv() override update *all* present versions of the

  2. Remove the use of the pg_auth flat file for client authentication.


On 12/15/2010 11:12 AM, Tom Lane wrote:
> Alvaro Herrera<alvherre@commandprompt.com>  writes:
>> This bug seems closely related to process_postgres_switches.  I guess
>> it'd be useful to add some debugging printouts there to figure out
>> what's being passed the second time around.
> It strikes me that the most obvious source for a platform dependency
> there would be getopt(), in particular the arrangements to cause getopt
> to behave sanely when we invoke it on a different argc array the second
> time around.  If that were failing for some reason, you could imagine
> getopt seeing 'postgres' as the next switch to parse, which could lead
> to the reported failure.
>
> Hence:
>
> 1. Is that build using src/port/getopt.c, or a library-supplied getopt?
> What about getopt_long.c?
>
> 2. Is HAVE_INT_OPTRESET getting defined?  Should it be?
>
> 			

I had the same thought. I did try forcing use of our getopt and 
getopt_long, without success, but didn't look at optreset.

cheers

andrew