On Sat, 2021-10-30 at 13:24 +0530, Bharath Rupireddy wrote: > IMHO, moving away from SQL command "CHECKPOINT" to function > "pg_checkpoint()" isn't nice as the SQL command has been there for a > long time and all the applications or services that were/are being > built around the postgres ecosystem would have to adapt someday to > the > new function (if at all we deprecate the command and onboard the > function). This isn't good at all given the CHECKPOINT is one of the > mostly used commands in the apps or services layer. Moreover, if we > go > with the function pg_checkpoint(), we might see patches coming in for > pg_vacuum(), pg_reindex(), pg_cluster() and so on.
I tend to agree with all of this. The CHECKPOINT command is already there and people already use it. If we are already chipping away at the need for superuser elsewhere, we should offer a way to use CHECKPOINT without being superuser. If the purpose[0] of predefined roles is that they allow you to do things that can't be expressed by GRANT, a predefined role pg_checkpointer seems to fit the bill. The main argument against[1] having a pg_checkpointer predefined role is that it creates a clutter of predefined roles. But it seems like just another part of the clutter of having a special SQL command merely for requesting a checkpoint. The alternative of creating a new function doesn't seem to alleviate the clutter. Some people will use the function and some will use the command, creating inconsistency in examples and scripts, and people will wonder which one is the "right" one. Regards, Jeff Davis [0] https://postgr.es/m/ca+tgmobqowzn62qwrx+oofjbphdubxytbeo-gsnpclvbhh4...@mail.gmail.com [1] https://postgr.es/m/8c661979-af85-4ae1-9e2b-2a091da3d...@amazon.com