Re: table AM option passing

Hi,

On 2026-03-17 20:47:22 +0100, Álvaro Herrera wrote:
> On 2026-Mar-17, Nathan Bossart wrote:
>
> > On Tue, Mar 17, 2026 at 05:50:41PM +0100, Álvaro Herrera wrote:
>
> > > (This change is vaguely similar to b7271aa1d71a, except I used 'int'
> > > instead of 'bits32', to keep the interface consistent with the existing
> > > heap_insert() one. Maybe I should make all three take bits64 instead?
> > > We don't actually have that type at present, so I'd have to add that
> > > too.)
> >
> > Why bits64 and not bits32? I must be missing something.
>
> augh, that's just a thinko -- yeah, we could use bits32 here and that
> wouldn't represent a reduction in number of possible flags.
>
> Does anybody oppose changing table_tuple_insert() to use bits32 instead
> of integer for the 'options' argument?

Personally I object to the existence of the bits* types, to me they're just
noise over using the corresponding unsigned integer types. One more thing that
one has to just know what it means without there being any actual improved
type checking or such. It's not like using bits* would make it any easier to
make the underlying type a struct or such (which is different to
e.g. TransactionId, we could probably replace that with a struct without crazy
amounts of trouble).

I think we should just rip the bits* types out and replace them with the
underlying types.

...

I do however think we should make the table_tuple_insert options argument
unsigned though. So I guess I might have to swallow the bitter pill of the
bits* type.

Greetings,

Andres Freund