Tom Lane wrote:
Claudio Natoli <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
