On Thu, Mar 26, 2026 at 12:07 PM Tomas Vondra <[email protected]> wrote: > > >> 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.
Yea, not allowing that doesn't really simplify the patch. But, talking to Andres off-list yesterday, he reminded me that users can simply add a new member to their table access method-specific scan descriptor (e.g. HeapScanDescData could get a new member). The value of flags lies in enabling table AM-agnostic executor code to pass flags through the table AM to the scan code. Besides my read-only hint scan option, he gave some examples -- like a hint to the scan that there is a LIMIT on the query. I think that is compelling. While exploring this, I realized that for a few internal flags, such as SO_ALLOW_STRAT and SO_ALLOW_SYNC, we have table scan functions, like table_beginscan_strat(), that accept parameters for setting those flags. They are basically the same as table_beginscan() but give users control over those flags. I think we can use the flags parameter to deprecate some of these specialized table scan functions. I think we can simplify the scan_rescan() callback as well. I don't think it makes sense to do it this late in the 19 release, though. All of those changes require having a flags parameter in the top level scan wrappers first. So, I think it is reasonable to do just that this release. - Melanie
