Robert Haas <robertmh...@gmail.com> writes: > On Fri, Dec 2, 2016 at 4:32 PM, Nico Williams <n...@cryptonector.com> wrote: >> What we do in Heimdal, OpenAFS, and other open source projects, some >> times, is include a copy / git submodule / similar of some such external >> dependencies. Naturally it's not possible to do this for all external >> dependencies, but it works well enough. The jv API part of jq is small >> and simple, and could be ripped out into a library that could be >> included in PostgreSQL.
> We are typically avoid copying things into our repository because then > we become responsible for pulling in any subsequent fixes. The few > instances that we have right now (zic, snowball, Harry Spencer's > regexp stuff) have imposed a significant code maintenance burden. The > git submodules approach might avoid that problem, but it would still > be the case that any compile-breaking bugs in the upstream repository > immediately become compile breaks for all PostgreSQL developers, and > that any critical defects that force emergency releases by the > upstream project now force emergency releases of PostgreSQL as well. > If we merely link against the external project, then we avoid that. Another point here is that packagers such as Red Hat strenuously dislike such source-code-level wrapping of other projects, because that means that they have to rebuild multiple packages to fix any bugs found in the wrapped code. If I were still packaging Postgres for Red Hat, and such a distribution landed in my inbox, the very first thing I'd be looking to do is rip out the borrowed code and replace it with a runtime shared-library dependency on the upstream project's official library. Having said that ... we have a *really bad* track record of deciding which outside projects we want to depend on, or maybe we've just outlived a lot of them. Aside from Robert's examples, there's uuid-ossp and libxml2, which are external code but have caused us headaches anyway. So I think there's a lot to be said for avoiding dependencies on libraries that may or may not still be getting actively maintained ten years from now. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers