On 3/26/26 15:51, Melanie Plageman wrote: > On Wed, Mar 25, 2026 at 7:29 PM Tomas Vondra <[email protected]> wrote: >> >>>> - Do we really want to pass two sets of flags to table_beginscan_common? >>>> I realize it's done to ensure "users" don't use internal flags, but >>>> then maybe it'd be better to do that check in the places calling the >>>> _common? Someone adding a new caller can break this in various ways >>>> anyway, e.g. by setting bits in the internal flags, no? >>> >>> Yes, callers of table_beginscan_common() could pass flags they >>> shouldn't in internal_flags. But I was mostly trying to prevent the >>> case where a user picks a flag that overlaps with an internal flag, >>> conditionally passes it as a user flag, and then when they test for it >>> in their AM-specific code, they aren't actually checking if their own >>> flag is set. >> >> Ah, so we expect people to invent their "own" flags, outside what's in >> ScanOptions? Or do I misunderstand how it works? (I admit not reading >> the whole massive thread, as I was only interested in using the flags in >> my own patch.) > > Yes, this isn't really explored in the rest of the thread. I thought > since the flags are threaded all the way through and they can > set/check the flags in the table AM-specific layer, it would make > sense that they could choose flags for their own purposes. They don't > have to wait for consensus on getting a new SO type added. I don't > know if this is a bad idea. However, changing the table AM wrappers > seems more justifiable if we are making them extensible in this way. >
No idea. Do we have an example of a TAM actually needing this? If not, I'd probably advise to remove that and keep the patch simpler. My past attempts to future-proof a patch like this rarely worked. If we want to give TAMs the opportunity to define custom flags, do we already do something like that elsewhere? Is there a precedent how to do that? If we allow the TAM to pick arbitrary flag values, it's easy to end up with collisions later (if we add a new internal flag). Maybe there is a way to prevent that? E.g. we could restrict internal flags to 0x0000FFFF, and custom flags to 0xFFFF0000? regards -- Tomas Vondra
