I removed that path because I interpreted the earlier discussion as asking me to avoid claiming that REPACK (ANALYZE) inherently performs transaction management, and I replaced it with a shorter comment explaining the current restriction.
I now understand your point that the comment should also explain the separate restriction on execution from a function/procedure/DO block. In particular, even if running REPACK (ANALYZE) inside a transaction block is reconsidered in the future, the restriction on execution from a function may still need to remain.
I'll update the comment to make that distinction explicit and will also follow the mailing-list preferred inline-posting style in future replies.
> I've updated the patch to address your comments: > > * Documented that 'REPACK (ANALYZE)' cannot be used inside a transaction block, or from a function, procedure or 'DO' block. > * Updated the comment in repack.c to clarify that this restriction is intentional for now, consistently with VACUUM (FULL, ANALYZE).
In [1] I added a comment explaining why it's a problem to run REPACK (ANALYZE) from function. I thought it's important so that, when we conclude (in the future) that running in block is fine, we still keep checking for execution from a function. (PreventInTransactionBlock() checks both at the moment.)
In [2] I was advised to make the comment more precise, but as you appear to have taken the patch over, I expected that you'll do that. However, you simply removed that part of the comment. Can you please explain why?
BTW, "top posting" is not the preferred style in this mailing list [3].
