From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Reloptions for table access methods |
Date: | 2021-01-02 18:44:20 |
Message-ID: | 1a711a06620254294c58a11dc339332b0e90d788.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2021-01-02 20:49:01 | Re: pgbench: option delaying queries till connections establishment? |
Previous Message | Andrey Borodin | 2021-01-02 16:54:39 | Re: archive status ".ready" files may be created too early |