On 4/20/21 8:47 AM, Robert Haas wrote:
> 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.
>
Yeah. I'll go along with Alvaro and say let's let sleeping dogs lie at
this stage of the dev process, and pick the discussion up after we branch.
I will just note one thing: the binaries in contrib have one important
function that hasn't been mentioned, namely to test using pgxs to build
binaries. That doesn't have to live in contrib, but we should have
something that does that somewhere in the build process, so if we
remmove oid2name and vacuumlo from contrib we need to look into that.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com