Login event trigger documentation wordsmithing
authorDaniel Gustafsson <[email protected]>
Thu, 14 Mar 2024 22:35:35 +0000 (23:35 +0100)
committerDaniel Gustafsson <[email protected]>
Thu, 14 Mar 2024 22:35:35 +0000 (23:35 +0100)
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 <[email protected]>
Discussion: https://postgr.es/m/CAJSLCQ0aMWUh1m6E9YdjeqV61baQ=EhteJX8XOxXg8H_2Lcr0Q@mail.gmail.com

doc/src/sgml/event-trigger.sgml
src/backend/commands/event_trigger.c

index 23dbb804819e78c4b694f2a2a67ce7cd0319e9b5..8e009cca050f2def75f384f0bbfc3deb2e20c151 100644 (file)
    <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>
 
index ab11ab500b2fa8458ab757bda743c31f3879226d..c95e9cf6f0efaee220932a192b0aa9880e2ac2a8 100644 (file)
@@ -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,