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+TgmoY=hCPE0piYnTe-6C2Tv4iMwjGQ7s+2YuLwP3YuqfSJPg@mail.gmail.com
Whole thread Raw
In response to Re: pg_amcheck option to install extension  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: pg_amcheck option to install extension  (Magnus Hagander <magnus@hagander.net>)
Re: pg_amcheck option to install extension  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On Mon, Apr 19, 2021 at 2:55 PM Andrew Dunstan <andrew@dunslane.net> wrote:
> There are at least two other client side programs in contrib. So this
> argument doesn't quite hold water from a consistency POV.

I thought that at first, too. But then I realized that those programs
are oid2name and vacuumlo. And oid2name, at least, seems like
something we ought to just consider removing. It's unclear why this is
something that really deserves a command-line utility rather than just
some additional psql options or something. Does anyone really use it?

vacuumlo isn't that impressive either, since it makes the very tenuous
assumption that an oid column is intended to reference a large object,
and the documentation doesn't even acknowledge what a shaky idea that
actually is. But I suspect it has much better chances of being useful
in practice than oid2name. In fact, I've heard of people using it and,
I think, finding it useful, so we probably don't want to just nuke it.

But the point is, as things stand today, almost everything in contrib
is an extension, not a binary. And we might want to view the
exceptions as loose ends to be cleaned up, rather than a pattern to
emulate.

It's a judgement call, though.

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: when the startup process doesn't
Next
From: Amit Kapila
Date:
Subject: Re: Table refer leak in logical replication