Re: Proposal: roll pg_stat_statements into core - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Proposal: roll pg_stat_statements into core
Date
Msg-id 20190904013858.GA17393@alvherre.pgsql
Whole thread Raw
In response to Re: Proposal: roll pg_stat_statements into core  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Proposal: roll pg_stat_statements into core
List pgsql-hackers
On 2019-Sep-03, Stephen Frost wrote:

> Greetings,
> 
> * David Fetter (david@fetter.org) wrote:
> > I'd like to $Subject, on by default, with a switch to turn it off for
> > those really at the outer edges of performance. Some reasons include:
> 
> Sure, half of contrib should really be in core (amcheck, file_fdw,
> postgres_fdw, maybe dblink, pageinspect, pg_buffercache,
> pg_freespacemap, pgstattuple, pg_visibility, sslinfo, maybe pgtrgm..)
> but we simply haven't got great facilities for either migrating those
> things into core (particularly during an upgrade..)

I think there is a false dichotomy here.  Migrating an extension out of
contrib doesn't have to equate making it no longer an extension.  We
could, instead, keep it being an extension, but move it out of contrib
and into (say) src/extensions/ so that it becomes installed and
available by default, but still an extension.  Users won't have to
install a separate contrib package, but they would still have to run
CREATE EXTENSION.

We don't incur the upgrade pain if we do that, for one thing.  Also, we
don't force everybody to have it; and we don't have to invent this
hypothetical switch to turn it off.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: remove "msg" parameter from convert_tuples_by_name
Next
From: Alvaro Herrera
Date:
Subject: Re: remove "msg" parameter from convert_tuples_by_name