Re: [Fwd: Re: regression failures on WIndows in machines with some non-English locales] - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [Fwd: Re: regression failures on WIndows in machines with some non-English locales]
Date
Msg-id 24790.1130852509@sss.pgh.pa.us
Whole thread Raw
In response to [Fwd: Re: regression failures on WIndows in machines with some non-English locales]  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: [Fwd: Re: regression failures on WIndows in machines  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> This has refreshed my fading memory. The patch seems like the best 
> solution. Is there any objection to applying it?

Putting the switch at the end seems certain to fail on some platforms
(some versions of getopt are fussier than others). 
>   bigtest:
> !     $(SHELL) ./pg_regress --schedule=$(srcdir)/serial_schedule --multibyte=$(MULTIBYTE) --load-language=plpgsql
numeric_big$(NOLOCALE) 
 
>   bigcheck:
> !     $(SHELL) ./pg_regress --temp-install --top-builddir=$(top_builddir) --temp-port=$(TEMP_PORT)
--schedule=$(srcdir)/parallel_schedule--multibyte=$(MULTIBYTE) --load-language=plpgsql $(MAXCONNOPT) numeric_big
$(NOLOCALE)

Put it with the other switches, and I won't object.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Adding a column in pg_proc for storing default values of arguments
Next
From: Tom Lane
Date:
Subject: Re: FreeBSD broke with autoconf-based build