Re: Tackling JsonPath support

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Dec 2, 2016 at 4:32 PM, Nico Williams <nico(at)cryptonector(dot)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