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-GSNPcLvBHh4ZvA@mail.gmail.com
[1] https://postgr.es/m/8C661979-AF85-4AE1-9E2B-2A091DA3DB22@amazon.com