On 3/25/26 19:54, Melanie Plageman wrote: > On Wed, Mar 25, 2026 at 2:02 PM Tomas Vondra <[email protected]> wrote: >> >> 0002 >> >> - Don't we usually keep "flags" as the last parameter? It seems a bit >> weird that it's added in between relation and snapshot. > > In an earlier review, Andres said he disliked using flags as the last > parameter for index_beginscan() because its current last two > parameters are integers (nkeys and norderbys), which could be > confusing. Personally, I think you have to look at the function > signature before just randomly passing stuff, and so it shouldn't > matter -- but I didn't care enough to argue. If you agree with me that > they should be last, then it's two against one and I'll change it back > :) I can keep the callsite comments naming the flags parameter. >
Who am I to argue with Andres? ;-) I'm kinda used to flags being the last argument, but it's not something I'm particularly attached to. >> - 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.) > Anyway, it's not hard to move: > Assert((flags & SO_INTERNAL_FLAGS) == 0); > into the table_beginscan_common() callers and then pass the internal > flags the caller wants to pass + the user specified flags to > table_beginscan_common(). And I think that fixes what you are talking > about? > Right. I wouldn't say it "fixes" it, because it wasn't a bug. But it does ensure the two sets do not "overlap", which I assume should never happen. >> If we want to have these checks, should we be more thorough? Should we >> check the internal flags only set internal flags? > > That's easy enough too. > Assert((internal_flags & ~SO_INTERNAL_FLAGS) == 0); I think does the trick. > > I think this would largely be the same as having > table_beginscan_common() callers validate that the user-passed flags > are not internal and then OR them together with the internal flags > they want to pass to table_beginscan_common(). > > I'm trying to think of cases where the two approaches would differ so > I can decide which to do. > OK -- Tomas Vondra
