Re: Proposal: roll pg_stat_statements into core

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Proposal: roll pg_stat_statements into core
Дата
Msg-id 20190904013858.GA17393@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: Proposal: roll pg_stat_statements into core  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Proposal: roll pg_stat_statements into core  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: remove "msg" parameter from convert_tuples_by_name
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: remove "msg" parameter from convert_tuples_by_name