Igor Korot <ikorot01@xxxxxxxxx> writes: > Imagine you are a developer/maintainer of sme software. This software needs to > connect to different DBMSes perform soe operations and then disconnect. > It is very easy to say that I have SQLite as a submodule in my Git tree, > I have mysql-connector as a submodule, but I can't have libpq this way > because it is hidden deep down inside PostgreSQL sources. To be blunt, that is an absolutely horrid way to distribute software. You should not, not, not be redistributing other people's code, because that puts you on the hook to keep up with their bug fixes --- particularly security-critical fixes, which do happen from time to time. That's a loop you don't want to be in. In this case I don't even see what's the point. If somebody wants to use your code with Postgres, it's just about certain that they already have an installed copy of libpq, from wherever they get Postgres from. The same argument applies to mysql or SQLite. So you should be expecting to link against already-present libraries, not bring your own. Do you bring your own libc, or openssl, or C compiler? I can tell you for certain that if your package were to be picked up and redistributed by Red Hat, or Debian, or any other open-source vendor, the very first thing they'd do is strip it of any such copied code. They don't want the management hassle of having to update multiple copies of libpq or mysql-connector or other stuff. regards, tom lane
