Re: table AM option passing

On 2026-Apr-01, Chao Li wrote:

> 1 - 0001
> For table_tuple_delete(), options is added and changingPart is
> removed, but the header comment should be updated to reflect the
> change.

True, fixed.

> 2 - 0002
> For table_tuple_update(), options is added, the header comment should
> be updated as well.

Done.

> 3 - 0002
> Now TABLE_INSERT_SKIP_FSM, TABLE_INSERT_FROZEN, TABLE_INSERT_NO_LOGICAL belong to the same options word as HEAP_INSERT_SPECULATIVE, but they are still defined as:
> ```
> #define TABLE_INSERT_SKIP_FSM 0x0002
> #define TABLE_INSERT_FROZEN 0x0004
> #define TABLE_INSERT_NO_LOGICAL 0x0008
> ```
>
> Could it make sense to change them to the left-shift form?

Yeah, I don't know. I don't like this style, but some people like it,
and I don't want to get into an argument about this kind of thing.

> 4 - 0002
> In heap_multi_insert(), heap_prepare_insert(), and heap_insert(),
> options is defined as uint32, but in RelationGetBufferForTuple() and
> raw_heap_insert() it is still defined as int. Would it make sense to
> take this opportunity to change all “options" to uint32 for
> consistency? Otherwise, if this is left for later, a trivial follow-up
> patch just to change int to uint32 may be harder to get processed.

Hmm, this is actually a problem in 1bd6f22f43ac. I added a preliminary
patch that should fix this.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"No renuncies a nada. No te aferres a nada."