Re: Modest proposal to extend TableAM API for controlling cluster commands - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: Modest proposal to extend TableAM API for controlling cluster commands
Date
Msg-id C63D2921-DBD3-44D6-8221-F027F5727649@enterprisedb.com
Whole thread Raw
In response to Re: Modest proposal to extend TableAM API for controlling cluster commands  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers

> On Jun 16, 2022, at 12:27 AM, Andres Freund <andres@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
cameacross as insulting.  I have a lot of respect for you, as do others at EDB, per invariably complementary comments
I'veheard 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'tbenefit from cluster or vacuum full, without the overhead of needlessly copying itself, and without causing
argumentlessVACUUM 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
communityapproval of the TAM's merits. 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Skipping logical replication transactions on subscriber side
Next
From: Konstantin Knizhnik
Date:
Subject: Re: SLRUs in the main buffer pool, redux