Re: pg_amcheck option to install extension
От | Andrew Dunstan |
---|---|
Тема | Re: pg_amcheck option to install extension |
Дата | |
Msg-id | 32266672-b711-ef72-079a-bfc0d8200cb9@dunslane.net обсуждение исходный текст |
Ответ на | Re: pg_amcheck option to install extension (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_amcheck option to install extension
|
Список | pgsql-hackers |
On 4/20/21 11:09 AM, Tom Lane wrote: > Alvaro Herrera <alvherre@alvh.no-ip.org> writes: >> Actually I think the best balance would be to leave things where they >> are, and move amcheck to src/extensions/ once the next devel cycle >> opens. That way, we avoid the (pretty much pointless) laborious task of >> moving pg_amcheck to contrib only to move it back on the next cycle. >> What I'm afraid of, if we move pg_amcheck to contrib, is that during the >> next cycle people will say that they are both perfectly fine in contrib/ >> and so we don't need to move anything anywhere. > Indeed. But I'm down on this idea of inventing src/extensions, > because then there will constantly be questions about whether FOO > belongs in contrib/ or src/extensions/. Unless we just move > everything there, and then the question becomes why bother. Sure, > "contrib" is kind of a legacy name, but PG is full of legacy names. > > I think the distinction I would draw is between things we would expect to be present in every Postgres installation (e.g. pg_stat_statements, auto_explain, postgres_fdw, hstore) and things we don't for one reason or another (e.g. pgcrypto, adminpack) cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: