Re: Reloptions for table access methods - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Reloptions for table access methods
Date
Msg-id 1a711a06620254294c58a11dc339332b0e90d788.camel@j-davis.com
Whole thread Raw
In response to Re: Reloptions for table access methods  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Reloptions for table access methods  (Simon Riggs <simon.riggs@enterprisedb.com>)
List 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 by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: archive status ".ready" files may be created too early
Next
From: Fabien COELHO
Date:
Subject: Re: pgbench: option delaying queries till connections establishment?