Re: stat() vs cygwin

Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>> Kenneth Marshall wrote:
>>
>>> One motivation for keeping it working on Cygwin, is that in some
>>> environments it is not allowed to install native Windows apps but
>>> they allow the use of the Cygwin environment. Of course if it takes
>>> too many resources to support, then dropping support would be an
>>> option. I would check this for you, but I am in the middle of moving
>>> and my Windows/Cygwin box is not available right now.
>>>
>>
>> Does anybody seriously have such a broken policy? I know a lot of places
>> who have inverse policy, where they don't allow cygwin, but I've never
>> heard of anybody refusing native programs and only allowing cygwin. Just
>> like I've heard of no linux shops requiring that you run your database
>> under wine...
>>
>>
>>
>
> This whole argument is pointless, ISTM. We are not in the business of
> telling people what environment to use Postgres in.

Well, agreed, the argument was that it should be dropped *IF* it turns
into a maintenance burden. Which it hasn't yet done.

> More to the point: I thought this had been tested. I will test it today
> so we can put this whole thread to rest.

IIRC it was only tested insofar that it doesn't actually break. Not if
it returns proper results.

Buf if my memory isn't completely off, there are other such cases as
well around the code, where we've done proper fixes for native win32 and
left cygwin alone. The argument being that for a developer system, it
doesn't really matter if things aren't entirely reliable, and that
nobody should be using cygwin for a production server. (I have nothing
against using it for a dev box, though I wouldn't do it myself)

//Magnus