On Fri, Aug 01, 2014 at 04:00:11PM -0700, Peter Geoghegan wrote:
> Since Robert did not give a
> reason for discussing the basic fmgr-elision patch despite having
> already discussed it a couple of years ago, I have not split the patch
> into two (if I did, the first patch would be virtually identical to
> Robert's 2012 patch). I hope that's okay. I am willing to revisit this
> question if Robert feels that something is uncertain about the costs
> and benefits of a basic fmgr-eliding sort support for text.
Robert, Heikki and maybe Alvaro requested and/or explained this split back in
April. The fact that the would-be first patch was discussed and rejected in
the past does not counter that request. (I voted against Robert's 2012 patch.
My opposition was mild even then, and the patch now being a stepping stone to
a more-compelling benefit certainly tips the scale.) Given that the effect of
that decision is a moderate procedural change only, even if the request were
wrong, why continue debating it?
> There are still some open items:
>
> * I have left the licensing question unresolved. There is plenty we
> can do about this, and if necessary we can ask the original author to
> changed his license from the MIT license to the PostgreSQL license.
> AFAICT, the BSD license is *more* restrictive than the MIT license,
> and the PostgreSQL license is identical. The wording is almost
> identical. I don't see the concern. If the PostgreSQL license had the
> “non-endorsement clause” of the New BSD license, or alternatively if
> the MIT license had a similar clause that the PostgreSQL licensed
> lacked, that would be a substantive and appreciable difference. That
> isn't the case.
It's fine to incorporate MIT-licensed code; we have many cases of copying
more-liberally-licensed code into our tree. However, it's important to have
long-term clarity on the upstream license terms. This is insufficient:
> + /*-------------------------------------------------------------------------
> + *
> + * hyperloglog.c
> + * HyperLogLog cardinality estimator
> + *
> + * Portions Copyright (c) 2014, PostgreSQL Global Development Group
> + *
> + * Based on Hideaki Ohno's C++ implementation. This is probably not ideally
> + * suited to estimating the cardinality of very large sets; in particular, we
Usually, the foreign file had a copyright/license notice, and we prepend the
PostgreSQL notice. See src/port/fls.c for a trivial example.
Thanks,
nm
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com