pgsql: Add reusable routine for making arrays unique.
Add reusable routine for making arrays unique.
Introduce qunique() and qunique_arg(), which can be used after qsort()
and qsort_arg() respectively to remove duplicate values. Use it where
appropriate.
Author: Thomas Munro
Reviewed-by: Tom Lane (in an earlier version)
Discussion: /messages/by-id/CAEepm=2vmFTNpAmwbGGD2WaryM6T3hSDVKQPfUwjdD_5XY6vAA@mail.gmail.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/7815e7efdb4ce9575b5d8460beb0dd2569d7ca3a
Modified Files
--------------
contrib/hstore/hstore_io.c | 5 +++
contrib/intarray/_int_tool.c | 19 +++--------
contrib/pg_trgm/trgm_op.c | 25 ++------------
src/backend/access/nbtree/nbtutils.c | 19 ++---------
src/backend/executor/nodeTidscan.c | 13 ++------
src/backend/utils/adt/acl.c | 15 +++------
src/backend/utils/adt/tsgistidx.c | 29 ++--------------
src/backend/utils/adt/tsquery_op.c | 29 +++-------------
src/backend/utils/adt/tsvector.c | 5 +--
src/backend/utils/adt/tsvector_op.c | 59 +++++---------------------------
src/backend/utils/adt/txid.c | 19 ++---------
src/backend/utils/cache/syscache.c | 21 ++++--------
src/include/lib/qunique.h | 65 ++++++++++++++++++++++++++++++++++++
13 files changed, 115 insertions(+), 208 deletions(-)
On Wed, Nov 6, 2019 at 8:03 PM Thomas Munro <tmunro@postgresql.org> wrote:
Add reusable routine for making arrays unique.
I noticed that some of the copyright notices added by this commit look
like this:
+ * Portions Copyright (c) 2019, PostgreSQL Global Development Group
Shouldn't this simply read "Copyright (c) 2019 ..."? We're not sharing
the Copyright with Regents of the University of California, or anyone
else, so there it is not just a portion.
It would be nice to have some general guidance on copyright notices in
new files. I usually just copy what I see in nearby files, but that
doesn't seem particularly principled.
--
Peter Geoghegan
On 2020-Jan-04, Peter Geoghegan wrote:
On Wed, Nov 6, 2019 at 8:03 PM Thomas Munro <tmunro@postgresql.org> wrote:
Add reusable routine for making arrays unique.
I noticed that some of the copyright notices added by this commit look
like this:+ * Portions Copyright (c) 2019, PostgreSQL Global Development Group
Shouldn't this simply read "Copyright (c) 2019 ..."? We're not sharing
the Copyright with Regents of the University of California, or anyone
else, so there it is not just a portion.
Looking at the stats, it's clear that it took a lot of code from other
files, so it seems disingenuous to claim that it doesn't have even a
single line that isn't copyrighted by UCB regents. I've seen this
argument used even for files that are completely new: they are likely
affected some API design aspect of existing code copyright of UCB
regents, so it too would have Portions (c) them.
It would be nice to have some general guidance on copyright notices in
new files. I usually just copy what I see in nearby files, but that
doesn't seem particularly principled.
I think the easiest is to state that all files, even new files are
Portions (c) each of these entities, period. Trying to distinguish code
that's not even a single line derived from UCB Regents seems really
labor-intensive.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Sun, Jan 5, 2020 at 5:39 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
Looking at the stats, it's clear that it took a lot of code from other
files, so it seems disingenuous to claim that it doesn't have even a
single line that isn't copyrighted by UCB regents.
I took that claim at face value. Perhaps it was just an oversight.
But if it really wasn't, then it's not just "portions" of the
copyright that go to the PGDG.
I think the easiest is to state that all files, even new files are
Portions (c) each of these entities, period. Trying to distinguish code
that's not even a single line derived from UCB Regents seems really
labor-intensive.
That seems like a reasonable policy to me, outside of third-party code
that gets vendored into the tree. I am also in favor of being
conservative about this.
--
Peter Geoghegan
On Sun, Jan 05, 2020 at 05:46:48PM -0800, Peter Geoghegan wrote:
On Sun, Jan 5, 2020 at 5:39 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
Looking at the stats, it's clear that it took a lot of code from other
files, so it seems disingenuous to claim that it doesn't have even a
single line that isn't copyrighted by UCB regents.I took that claim at face value. Perhaps it was just an oversight.
But if it really wasn't, then it's not just "portions" of the
copyright that go to the PGDG.I think the easiest is to state that all files, even new files are
Portions (c) each of these entities, period. Trying to distinguish code
that's not even a single line derived from UCB Regents seems really
labor-intensive.That seems like a reasonable policy to me, outside of third-party code
that gets vendored into the tree. I am also in favor of being
conservative about this.
That's also a no-brainer. So +1 to that. If we were to make that
more formal, could we add something in the docs in [1]https://www.postgresql.org/docs/12/source.html -- Michael? An idea could
be a new section dedicated to it.
[1]: https://www.postgresql.org/docs/12/source.html -- Michael
--
Michael
On 2020-Jan-06, Michael Paquier wrote:
On Sun, Jan 05, 2020 at 05:46:48PM -0800, Peter Geoghegan wrote:
On Sun, Jan 5, 2020 at 5:39 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
I think the easiest is to state that all files, even new files are
Portions (c) each of these entities, period. Trying to distinguish code
that's not even a single line derived from UCB Regents seems really
labor-intensive.That seems like a reasonable policy to me, outside of third-party code
that gets vendored into the tree. I am also in favor of being
conservative about this.That's also a no-brainer. So +1 to that. If we were to make that
more formal, could we add something in the docs in [1]? An idea could
be a new section dedicated to it.
That seems too extreme for me. I'm happy to leave it as a gentlemen's
agreement.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services