On 1 June 2016 at 13:09, Tsunakawa, Takayuki <tsunakawa.ta...@jp.fujitsu.com > wrote:
> From: pgsql-hackers-ow...@postgresql.org [mailto: > pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer > > 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. > > > https://www.postgresql.org/docs/devel/static/install-windows-full.html#AEN30192 > 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. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
