Re: Why not install pgstattuple by default?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Why not install pgstattuple by default?
Date: 2011-05-07 16:26:40
Message-ID: 8713.1304785600@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <gsstark(at)mit(dot)edu> writes:
> On Fri, May 6, 2011 at 11:32 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
>> I use pgstattuple, pageinspect, pg_freespacemap, and pg_buffercache
>> regularly enough that I wish they were more common. Throw in pgrowlocks and
>> you've got the whole group Robert put into the debug set. It makes me sad
>> every time I finish a utility using one of these and realize I'll have to
>> include the whole "make sure you have the contrib modules installed"
>> disclaimer in its documentation again.

> Well the lightweight way to achieve what you want is to just move
> these functions into core.

I'm completely not in favor of that. We have spent man-years upon
man-years on making Postgres an extensible system. If we can't actually
*use* the extension features then that was all a waste of effort.

If anything I'd rather see us looking at what parts of the current core
system could be pushed out to extensions. The geometric types are a
pretty obvious candidate, for example.

> The only argument I see as particularly frightening on that front is
> people playing the sekurity card.

Yeah, and it's a reasonable argument. Even if it's not a reasonable
argument, you won't win any friends from the other side of the fence
by taking away their ability to choose.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-05-07 16:34:34 Re: switch UNLOGGED to LOGGED
Previous Message Bruce Momjian 2011-05-07 16:21:12 Re: Fix for pg_upgrade user flag