Обсуждение: Use of reloptions by EXTENSIONs
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.
Dent John <denty@qqdd.eu> writes: > I guess my question is, and I correctly understanding that reloptions are basically off-limits to EXTENSIONS? IIRC that's basically true. There's a lot of dissatisfaction with the current implementation of reloptions, although I think that it's been mainly focused on the fact that adding new ones is hard/error-prone even within the core code. If you want to help move this along, you could review the existing patch in the area: https://www.postgresql.org/message-id/flat/2083183.Rn7qOxG4Ov@x200m and/or propose additional changes. regards, tom lane
Thank you, Tom. (And sorry for the delay following up.) I’ve marked myself down for review for this patch in the next CF. I’ll see if I can get the patch applied and feed back on how much it move towards making my use case a viable proposition. d. > On 9 Jun 2019, at 17:21, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Dent John <denty@qqdd.eu> writes: >> I guess my question is, and I correctly understanding that reloptions are basically off-limits to EXTENSIONS? > > IIRC that's basically true. There's a lot of dissatisfaction with the > current implementation of reloptions, although I think that it's been > mainly focused on the fact that adding new ones is hard/error-prone > even within the core code. If you want to help move this along, you > could review the existing patch in the area: > > https://www.postgresql.org/message-id/flat/2083183.Rn7qOxG4Ov@x200m > > and/or propose additional changes. > > regards, tom lane
On Mon, Jun 24, 2019 at 11:47:09AM +0200, Dent John wrote: > I’ll see if I can get the patch applied and feed back on how much it > move towards making my use case a viable proposition. There is another patch which provides more coverage for reloptions: https://commitfest.postgresql.org/23/2064/ Based on my last lookup, I was rather unhappy with its shape because of the assumptions behind the tests and the extra useless work it was doing with parameter strings (the set of WARNING is also something we don't need). If we get that first in, we can then make sure that any extra refactoring has hopefully no impact. -- Michael