From 4665cebc8a01dabd54b000bcc107a3468be3a81c Mon Sep 17 00:00:00 2001
From: Daniel Gustafsson <dgustafsson@postgresql.org>
Date: Thu, 14 Mar 2024 23:35:35 +0100
Subject: [PATCH] Login event trigger documentation wordsmithing
Minor wordsmithing on the login trigger documentation and code
comments to improve readability, as well as fixing a few small
incorrect statements in the comments.
Author: Robert Treat <rob@xzilla.net>
Discussion: https://postgr.es/m/CAJSLCQ0aMWUh1m6E9YdjeqV61baQ=EhteJX8XOxXg8H_2Lcr0Q@mail.gmail.com
---
doc/src/sgml/event-trigger.sgml | 10 +++++-----
src/backend/commands/event_trigger.c | 18 +++++++++---------
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/doc/src/sgml/event-trigger.sgml b/doc/src/sgml/event-trigger.sgml
index 23dbb80481..8e009cca05 100644
--- a/doc/src/sgml/event-trigger.sgml
+++ b/doc/src/sgml/event-trigger.sgml
@@ -39,10 +39,10 @@
<para>
The <literal>login</literal> event occurs when an authenticated user logs
into the system. Any bug in a trigger procedure for this event may
- prevent successful login to the system. Such bugs may be fixed by
- setting <xref linkend="guc-event-triggers"/> is set to <literal>false</literal>
- either in a connection string or configuration file. Alternative is
- restarting the system in single-user mode (as event triggers are
+ prevent successful login to the system. Such bugs may be worked around by
+ setting <xref linkend="guc-event-triggers"/> to <literal>false</literal>
+ either in a connection string or configuration file. Alternatively, you can
+ restart the system in single-user mode (as event triggers are
disabled in this mode). See the <xref linkend="app-postgres"/> reference
page for details about using single-user mode.
The <literal>login</literal> event will also fire on standby servers.
@@ -50,7 +50,7 @@
writing anything to the database when running on a standby.
Also, it's recommended to avoid long-running queries in
<literal>login</literal> event triggers. Note that, for instance,
- canceling connection in <application>psql</application> wouldn't cancel
+ canceling a connection in <application>psql</application> will not cancel
the in-progress <literal>login</literal> trigger.
</para>
diff --git a/src/backend/commands/event_trigger.c b/src/backend/commands/event_trigger.c
index ab11ab500b..c95e9cf6f0 100644
--- a/src/backend/commands/event_trigger.c
+++ b/src/backend/commands/event_trigger.c
@@ -174,7 +174,7 @@ CreateEventTrigger(CreateEventTrigStmt *stmt)
else if (strcmp(stmt->eventname, "login") == 0 && tags != NULL)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
- errmsg("tag filtering is not supported for login event trigger")));
+ errmsg("tag filtering is not supported for login event triggers")));
/*
* Give user a nice error message if an event trigger of the same name
@@ -307,7 +307,7 @@ insert_event_trigger_tuple(const char *trigname, const char *eventname, Oid evtO
heap_freetuple(tuple);
/*
- * Login event triggers have an additional flag in pg_database to avoid
+ * Login event triggers have an additional flag in pg_database to enable
* faster lookups in hot codepaths. Set the flag unless already True.
*/
if (strcmp(eventname, "login") == 0)
@@ -376,7 +376,7 @@ filter_list_to_array(List *filterlist)
/*
* Set pg_database.dathasloginevt flag for current database indicating that
- * current database has on login triggers.
+ * current database has on login event triggers.
*/
void
SetDatatabaseHasLoginEventTriggers(void)
@@ -444,7 +444,7 @@ AlterEventTrigger(AlterEventTrigStmt *stmt)
CatalogTupleUpdate(tgrel, &tup->t_self, tup);
/*
- * Login event triggers have an additional flag in pg_database to avoid
+ * Login event triggers have an additional flag in pg_database to enable
* faster lookups in hot codepaths. Set the flag unless already True.
*/
if (namestrcmp(&evtForm->evtevent, "login") == 0 &&
@@ -695,7 +695,7 @@ EventTriggerCommonSetup(Node *parsetree,
}
}
- /* don't spend any more time on this if no functions to run */
+ /* Don't spend any more time on this if no functions to run */
if (runlist == NIL)
return NIL;
@@ -878,7 +878,7 @@ EventTriggerSQLDrop(Node *parsetree)
/*
* Fire login event triggers if any are present. The dathasloginevt
- * pg_database flag is left when an event trigger is dropped, to avoid
+ * pg_database flag is left unchanged when an event trigger is dropped to avoid
* complicating the codepath in the case of multiple event triggers. This
* function will instead unset the flag if no trigger is defined.
*/
@@ -891,7 +891,7 @@ EventTriggerOnLogin(void)
/*
* See EventTriggerDDLCommandStart for a discussion about why event
* triggers are disabled in single user mode or via a GUC. We also need a
- * database connection (some background workers doesn't have it).
+ * database connection (some background workers don't have it).
*/
if (!IsUnderPostmaster || !event_triggers ||
!OidIsValid(MyDatabaseId) || !MyDatabaseHasLoginEventTriggers)
@@ -920,7 +920,7 @@ EventTriggerOnLogin(void)
/*
* There is no active login event trigger, but our
- * pg_database.dathasloginevt was set. Try to unset this flag. We use the
+ * pg_database.dathasloginevt is set. Try to unset this flag. We use the
* lock to prevent concurrent SetDatatabaseHasLoginEventTriggers(), but we
* don't want to hang the connection waiting on the lock. Thus, we are
* just trying to acquire the lock conditionally.
@@ -931,7 +931,7 @@ EventTriggerOnLogin(void)
/*
* The lock is held. Now we need to recheck that login event triggers
* list is still empty. Once the list is empty, we know that even if
- * there is a backend, which concurrently inserts/enables login
+ * there is a backend which concurrently inserts/enables a login event
* trigger, it will update pg_database.dathasloginevt *afterwards*.
*/
runlist = EventTriggerCommonSetup(NULL,