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

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

Reply via email to