Hi folks, I’ve been paying my query-rewrite for MVs EXTENSION a bit of attention recently, and I was looking at how to enable people to turn it on and off without requiring a user of it to get too much into it’s guts.
However, the add_X_reloption() APIs seems to need to be paired with a change to core code, and so that rather puts them off limits for EXTENSIONs. I wonder if I’m understanding or using it wrong. My specific use case is how to flag a given MV as being a potential candidate that it is worth my EXTENSION’s logic (which runs in the planner, so is relatively time-sensitive) reviewing it for a match against the currently-being-planned query. The significant end user in my use case is a DBA, or the DB-skilled dev in a dev team. GUCs look a bit of a hack for this use case, so I’ve dismissed them. Around the EXTENSION landscape, people seem to use pgplsql packages to admin. This also seems a bit hacky, especially as the way people typically illustrate them is to SELECT from some administrative function. It works, and it’s low tech. TBH, it has the advantage of being the “accepted way” on PostgreSQL, and I’ve seen similar in Oracle, so it’s not without precedent. I can see why generalised extensions to the SQL parser are basically not starters. But reloptions, or “storage_parameters”, seem syntactically just the ticket. I’m envisaging something like “ALTER MV xyz SET (rewrite_enabled = true)”. I guess my question is, and I correctly understanding that reloptions are basically off-limits to EXTENSIONS? I did see a long 2014 thread discussing, and that got quite heated. So perhaps it is still a tricky question to answer... To develop my question a bit more... I wonder if I’ve stumbled upon use case that should work, but doesn’t. Have I found a bug? (Which leads obviously to, should it be fixed?) Thanks, d.
