Re: msvc failure in largeobject regression test - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: msvc failure in largeobject regression test
Date
Msg-id 45F2A84C.3030106@dunslane.net
Whole thread Raw
In response to Re: msvc failure in largeobject regression test  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>   
>> Magnus Hagander wrote:
>> I wonder if this is a line-end issue? Assuming you are working from CVS,
>> does your client turn \n into \r\n ?
>>     
>
>   
>> I have just run into this today while trying to get buildfarm working 
>> for MSVC. After some consideration I think an alternative result file is 
>> the best solution. I have looked at switches for cnsnt, but they are 
>> likely to be fragile at best.
>>     
>
> Are you proposing an alternate result file that has a different linefeed
> style?  I would really really rather that we not go there, because it
> will be impossibly fragile to maintain.  Or are you willing to accept
> that the Windows builds will break every time someone changes that
> regression test, until someone else with a Windows machine fixes the
> result file?
>
> I would find it preferable to make pg_regress compensate for this
> issue somehow ...
>
>   
No, the alternate results file does not use different line feeds, and is 
as you would wish not sensitive to line-end style. I was careful (I hope 
careful enough) to make sure that the file I checked in didn't have a 
single CR in it. It just reflects the results obtained when tenk.data 
file is checked out with CRLF line endings and then used for LO input. 
The alternative as you say is that we make pg_regress perform some sort 
of dos2unix on the data file. I note that tenk.data hasn't changed in 4 
years.

cheers

andrew



pgsql-hackers by date:

Previous
From: "Pavan Deolasee"
Date:
Subject: Re: Bug in VACUUM FULL ?
Next
From: "Simon Riggs"
Date:
Subject: Re: [PATCHES] scan_recycle_buffers