pgsql: Add DISTINCT to information schema usage views
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t222661psql -h localhost -U postgresBuilt from patchset v2 (message #2), July 29, 2026 at 12:54 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t222661_2 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t222661_2 && git checkout t222661_2Patchset v2 (message #2) is on t222661_2
Add DISTINCT to information schema usage views
Since pg_depend can contain duplicate entries, we need to eliminate
those in information schema views that build on pg_depend, using
DISTINCT. Some of the older views already did that correctly, but
some of the more recently added ones didn't. (In some of these views,
it might not be possible to reproduce the issue because of how the
implementation happens to deduplicate dependencies while recording
them, but it seems better to keep this consistent in all cases.)
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/d84ffffe582b8e036a14c6bc2378df29167f3a00
Modified Files
--------------
src/backend/catalog/information_schema.sql | 18 ++++++++++++------
src/include/catalog/catversion.h | 2 +-
2 files changed, 13 insertions(+), 7 deletions(-)
On Wed, 21 Apr 2021 at 22:32, Peter Eisentraut <peter@eisentraut.org> wrote:
Add DISTINCT to information schema usage views
What do you think of the idea of just getting rid of all these
DISTINCTs and instead do a semi-join so that we don't get duplicate
rows?
For me, I don't really like the DISTINCTs as the behaviour is prone to
change as the target list changes in the view. Maybe these views are
standard enough that that's not going to happen very often, but it
could.
The 2nd reason I'm not a fan of using DISTINCT is that it's really
chopping the problem off at the tail instead of the head.
I've attached a patch that gets rid of all the DISTINCTs.
David