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
peopleto 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
offlimits 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
(whichruns in the planner, so is relatively time-sensitive) reviewing it for a match against the
currently-being-plannedquery. 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
asthe 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
withoutprecedent.
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
xyzSET (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
founda bug? (Which leads obviously to, should it be fixed?)
Thanks,
d.