Re: Reloptions for table access methods

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Reloptions for table access methods
Дата
Msg-id 1a711a06620254294c58a11dc339332b0e90d788.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: Reloptions for table access methods  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: Reloptions for table access methods  (Simon Riggs <simon.riggs@enterprisedb.com>)
Список pgsql-hackers
On Wed, 2020-12-30 at 21:23 +0000, Simon Riggs wrote:
> But you cannot seriously argue that a one line patch that changes
> user
> visible behavior can be acceptable in Postgres core without tests or
> docs or code comments.

Hi Simon,

Often, good documented APIs come about after a few extensions gain
experience hacking things together using undocumented assumptions and
internal APIs. But in this case, extension authors have no opportunity
to hack in reloptions for a TableAM, because of this needless extra
check that my patch would eliminate.

The patch does not have any user-visible impact. To have any effect, an
extension would need to use these internal APIs in a specific way that
is not documented externally. I see my tiny patch as a tiny improvement
to the backend code because it eliminates a useless extra check, and
therefore doesn't need much justification. If others see it as a burden
on the engine code, that's a different story.

If we insist that this must be a fully-supported feature or nothing at
all, then I'll withdraw the patch. But I doubt that will result in a
proper feature for v14, it just means that when we do get around to
supporting extensible reloptions, there will be no hacks in the wild to
learn from.

Regards,
    Jeff Davis





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrey Borodin
Дата:
Сообщение: Re: archive status ".ready" files may be created too early
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: pgbench: option delaying queries till connections establishment?