Re: Freeze avoidance of very large table. - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Freeze avoidance of very large table.
Date
Msg-id CA+TgmoavjSoGRB5NGOc4jtatXt8DHoqf9PM72MHFi3skY4WRfg@mail.gmail.com
Whole thread Raw
In response to Re: Freeze avoidance of very large table.  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: Freeze avoidance of very large table.  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Thu, Aug 6, 2015 at 11:33 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> They also provide a level of control over what is and isn't installed in a
> cluster. Personally, I'd prefer that most users not even be aware of the
> existence of things like pageinspect.

+1.

If everybody feels that moving extensions currently stored in contrib
into src/extensions is going to help us somehow, then, uh, OK.  I
can't work up any enthusiasm for that, but I can live with it.

However, I think it's affirmatively bad policy to say that we're going
to put all of our debugging facilities into core because otherwise
some people might not have them installed.  That's depriving users of
the ability to control their environment, and there are good reasons
for some people to want those things not to be installed.  If we
accept the argument "it inconveniences hacker X when Y is not
installed" as a reason to put Y in core, then we can justify putting
anything at all into core.  And I don't think that's right at all.
Extensions are a useful packaging mechanism for functionality that is
useful but not required, and debugging facilities are definitely very
useful but should not be required.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: cache invalidation skip logic
Next
From: Tom Lane
Date:
Subject: Re: Assert in pg_stat_statements