While that's probably OK, it's not especially desirable. The typical Windows deployment model involves the application bundling all its direct dependencies except when those are provided by a runtime redistributable designed for that purpose.
I think so, too, but I'm not confident that's typical. Some people may think of PostgreSQL binaries as a shared component for their applications and place it in one place, just like the PostgreSQL library package is in /usr/lib/pgsql.
(Your reply formatting seems mangled, mixing my text with yours)
/usr/lib/pgsql works because *nix systems don't typically do binary distribution.
Windows apps that rely on binary distribution should bundle the libraries they require.
Maybe a note on windows distribution in the libpq manual would be warranted. I thought it was so accepted as the way it's done that nobody would really do anything else.
(Then again, EDB's installers don't bundle their Python, Perl, etc runtimes, but I think that's partly a legal thing).
There's a client-only installation method as follows, although I haven't checked whether EnterpriseDB, OpenSCG, or any other PostgreSQL-based products provide client-only installation.
Right, and EDBs installers also let you install just the client AFAIK, but there's no simple client library redist package, like you'd expect if it was intended for use that way.
