* Dave Page (dp...@pgadmin.org) wrote: > Because if we (PostgreSQL) are going to support this effort, then it > should not ignore such a huge percentage of our installation base.
Not doing it day 1 is not ignoring. It's using what resources *are*
being made available to the best extent we can. If you're offering to
do the work for Windows, great!
> > It would make sense to build a C version when the other issues with
> > supporting Windows are solved. At that point, the specification for the
> > client should be well-worn enough to make doing the C version not a halt
> > to further development. Until then, it doesn't matter.
>
> So you have to rewrite the code. Seems like a waste of effort.
So the options are some Perl code that works for quite a few users or..
nothing because he's not a C hacker or doesn't want to write it in C?
Sounds like #1 is a win to me. If David's happy to write it in C to
begin with (presuming he has to write anything- if there's existing Perl
code that does 90% of what he needs, you're asking for alot more),
great. I'm even happy to encourage him to do that if it's anywhere
close to the same level of effort.
> No. The essence is, 'If you're going to do it in a way that will never
> work for maybe 50% or more of PostgreSQL installations, then you have
> fundamental design issues to overcome'.
And my vote is that you have to start somewhere and I strongly disagree
that what you're concerned with are serious *design* issues. What David
has described includes alot of implementation details, let's not confuse
the two. If the server-side had to be scrapped entirely and rewritten
to support Windows, you might have a leg to stand on. If adding Windows
support is an incremental change to the existing system (as a whole,
which, yes, I'd consider the port of a perl client app to C to be an
incremental change), then it's not a design issue.
Thanks,
Stephen
signature.asc
Description: Digital signature
