Re: pg_amcheck option to install extension - Mailing list pgsql-hackers

From Robert Haas
Subject Re: pg_amcheck option to install extension
Date
Msg-id CA+TgmoZY9Kzymfz_SyGzu+mNQjPOjkpfsUXHL7ebb1H_Y1ecPg@mail.gmail.com
Whole thread Raw
In response to Re: pg_amcheck option to install extension  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Apr 20, 2021 at 12:05 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > I think the distinction I would draw is between things we would expect
> > to be present in every Postgres installation (e.g. pg_stat_statements,
> > auto_explain, postgres_fdw, hstore) and things we don't for one reason
> > or another (e.g. pgcrypto, adminpack)
>
> I dunno, that division appears quite arbitrary and endlessly
> bikesheddable.

+1. I wouldn't expect those things to be present in every
installation, for sure. I don't know that I've *ever* seen a customer
use hstore. If I have, it wasn't often. There's no way we'll ever get
consensus on which stuff people use, because it's different depending
on what customers you work with.

The stuff I feel bad about is stuff like 'isn' and 'earthdistance' and
'intarray', which are basically useless toys with low code quality.
You'd hate for people to confuse that with stuff like 'dblink' or
'pgcrypto' which might actually be useful. But there's a big, broad
fuzzy area in the middle where everyone is going to have different
opinions. And even things like 'isn' and 'earthdistance' and
'intarray' may well have defenders, either because somebody thinks
it's valuable as a coding example, or because somebody really did use
it in anger and had success.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Synchronous commit behavior during network outage
Next
From: Bruce Momjian
Date:
Subject: Re: Problems around compute_query_id