On Thu, Feb 26, 2026 at 8:55 AM Robert Haas <robertmhaas@gmail.com> wrote:
> Thanks, Alex, for the review.
Here's v18. In addition to fixing the problems pointed out by Alex,
there are a couple of significant changes in this version.
I have a mind to walk through the readmes and sgmls but its going to be in chunks. Here's one for the readme for pg_plan_advice with a couple of preliminary sgml changes.
0003 sgml focus with some readme.
And now 0004 sgml (no readme):
Lastly, 0007 sgml (stash)
Placed entry in correct position on contrib page.
Expanded a bit on the security aspect comment. I suppose there is some indirect exposure via decisions being made implying table sizes or records-per-FK...I left that unmentioned.
Added some explicit limitations to user-supplied values.
I would personally like to see "pg_set_stashed_advice" returning something besides void. I would usually go for text, but maybe in the interest of i18n an integer would suffice. +1 if a row was added, -1 if a row is removed, or 0 for an update. That would necessitate any other no-op being an error. Presently, supplying NULL for the query_id is not an error - that seems like an oversight. Same goes for supplying NULL for stash_name. If both of those cases produce errors (leaving NULL advice_string being a remove indicator) the integer return seems like it should work just fine.
Sorta feels like this module would appreciate advice strings having a comment feature - so instead of just leaving an empty string behind saying "we know, no advice needed" - it could contain actual content that isn't applied advice. Given the complexity of planning, comments seem warranted in the advice themselves in any case.
Feels like this module needs export and import functions, especially given the intro paragraph about the contents being volatile. Or maybe a psql script example producing a dynamic script file involving \gexec.
David J.
