Re: pg_amcheck option to install extension
От | Alvaro Herrera |
---|---|
Тема | Re: pg_amcheck option to install extension |
Дата | |
Msg-id | 20210420145140.GA2451@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: pg_amcheck option to install extension (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: pg_amcheck option to install extension
|
Список | pgsql-hackers |
On 2021-Apr-20, Michael Paquier wrote: > Agreed. Something like src/extensions/ would be a tempting option, > but I don't think that it is a good idea to introduce a new piece of > infrastructure at this stage, so moving both to contrib/ would be the > best balance with the current pieces at hand. 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. And next time someone wants to create a new extension that would be perfectly fine in core, they will not want to have that one be the one that creates src/extensions/, because then that in itself is a contentious point that can get the whole patch rejected. In a sense, what I'm doing is support the idea that "incremental development" applies to procedure too. -- Álvaro Herrera 39°49'30"S 73°17'W
В списке pgsql-hackers по дате отправления: