Re: Modest proposal to extend TableAM API for controlling cluster commands

Hi,

On 2022-06-15 22:23:36 -0700, Mark Dilger wrote:
> I'm not entirely against you on that, but it makes me cringe that we impose
> design decisions like that on any and all future TAMs. It seems better to
> me to let the TAM author decide to emit an error, warning, notice, or
> whatever, as they see fit.

The tradeoff is that that pushes down complexity and makes the overall system
harder to understand. I'm not saying that there's no possible use for such
callbacks / configurability, I'm just not convinced it's worth the cost.

> >> But I can't really complete my work with the interface as it stands
> >> now.
> >
> > Since you've not described that work to a meaningful degree...
>
> I don't think I should have to do so. It's like saying, "I think I should
> have freedom of speech", and you say, "well, I'm not sure about that; tell
> me what you want to say, and I'll decide if I'm going to let you say it".'
> That's not freedom. I think TAM authors should have broad discretion over
> anything that the core system doesn't have a compelling interest in
> controlling.

That's insultingly ridiculous. You can say, do whatever you want, but that
doesn't mean I have to be convinced by it (i.e. +1 adding an API) - that'd be
compelled speech, to go with your image...

It's utterly normal to be asked what the use case for a new API is when
proposing one.

> You've not yet said why a TAM should be prohibited from opting
> out of cluster/vacfull.

API / behavioural complexity. If we make ever nook and cranny configurable,
we'll have an ever harder to use / administer system (from a user's POV) and
have difficulty understanding the state of the system when writing patches
(from a core PG developer's POV). It might be the right thing in this case -
hence me asking for what the motivation is.

Greetings,

Andres Freund