> On Jun 16, 2022, at 12:27 AM, Andres Freund <and...@anarazel.de> wrote:
>
>> 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...
Indeed it would be compelled speech, and I'm not trying to compel you, only to
convince you. And my apologies if it came across as insulting. I have a lot
of respect for you, as do others at EDB, per invariably complementary comments
I've heard others express.
> It's utterly normal to be asked what the use case for a new API is when
> proposing one.
It seems like we're talking on two different levels. I've said what the use
case is, which is to implement a TAM that doesn't benefit from cluster or
vacuum full, without the overhead of needlessly copying itself, and without
causing argumentless VACUUM FULL commands to fail. I'm *emphatically* not
asking the community to accept the TAM back as a patch. The freedom I'm
talking about is the freedom to design and implement such a third-party TAM
without seeking community approval of the TAM's merits.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
