Tom Lane wrote:
>Claudio Natoli <claudio.natoli@memetrics.com> writes:
>
>
>>* Users already have a postgres solution for Win32. It is called Cygwin w/
>>cygipc. Sure, it is not the most stable solution, but, IMHO, that's not what
>>prevents people from using it; it is the need to install yet-another bit of
>>software to support Postgres.
>>
>>
>
>Well, the $64 questions that have not been answered are what are the
>license terms and redistribution terms for SFU? If we can bundle the
>needed parts of SFU into a binary distribution of Postgres, then there
>is no need for users to be aware it is in there. If we can't, then
>I agree that a port based on it would be about as hard to sell as the
>Cygwin port. (Yeah, maybe it'd be more stable and faster, but it'd not
>be perceived as a native port.)
>
I suspect it would be somewhere in between. I can tell you from personal
experience that getting Cygwin into a large data centre can be very
hard, if not impossible. The techno-bureaucrats that run them can be
(understandably) very anal and paranoid about what they allow on their
machines. If you are running a bank or a nuclear power station it is the
only sensible way to be. (You might argue that banks and nuclear power
stations should not be controlled by Windows machines - but that's
another argument - let's not go there right now ;-)
I don't think I would have encountered as much resistance to getting
WSFU onto these machines - some, but not as much.
The licensing issue does affect companies like the one I used to work
for, that wanted to be able to bundle a database with the product.
>
>Given the previous comments about Microsoft's goals in giving this away,
>one would think they'd allow it to be bundled in distributions of free
>software. But who knows ...
>
Not me :-)
>
>
>
>>* I don't buy the argument that moving to SFU will remove a lot of specific
>>Win32 code. On what evidence is this based on? [personally, I think it'd
>>only get worse, again, based on little evidence]. Seems to me the bulk of
>>the Win32 specific code lies with fork/exec, which (unless I'm terribly
>>mistaken) won't be alleviated by SFU.
>>
>>
>
>If SFU doesn't provide a reasonable fork() emulation then it's no help,
>agreed. But again, from what I understand of Microsoft's goals, I'd
>think they'd have to provide a good fork(). I think Postgres is a
>perfect poster child for the sort of app they want to make easy to port
>to Windows.
>
>
>
Agreed. I think this is worth exploring, but I don't think it's worth
stopping what we are doing right now while we explore.
Note that the migration guide says that threads are not supported. So if
we ever went to a threaded implementation we could not go down this path.
cheers
andrew