pg_listen

pg_listen — Set a callback for asynchronous notification messages

Synopsis

pg_listen conn notifyName ?callbackCommand?

Description

pg_listen creates, changes, or cancels a request to listen for asynchronous notification messages from the PostgreSQL server. With a callbackCommand parameter, the request is established, or the command string of an already existing request is replaced. With no callbackCommand parameter, a prior request is canceled.

After a pg_listen request is established, the specified command string is executed whenever a notification message bearing the given name arrives from the server. This occurs when any PostgreSQL client application issues a NOTIFY command referencing that name. The command string is executed from the Tcl idle loop. That is the normal idle state of an application written with Tk. In non-Tk Tcl shells, you can execute update or vwait to cause the idle loop to be entered.

You should not invoke the SQL statements LISTEN or UNLISTEN directly when using pg_listen. pgtcl takes care of issuing those statements for you. But if you want to send a notification message yourself, invoke the SQL NOTIFY statement using pg_exec.

Arguments

conn

The handle of the connection on which to listen for notifications.

notifyName

The name of the notification condition to start or stop listening to. Starting with PostgreSQL-9.0, this is referred to as a channel by the PostgreSQL documentation.

callbackCommand

If present, provides the command string to execute when a matching notification arrives. If absent, an existing command string for matching notification is canceled. The command string should be the name of a Tcl procedure (possibly with leading arguments specified), which also accepts an optional additional argument for the notification payload. See the notes below for details.

Return Value

Nothing. Throws a Tcl error if an error occurs.

Notes

Starting with PostgreSQL-9.0, a notification message can include a payload string. An example of SQL to send a notification with payload is:

NOTIFY my_channel, 'the payload'

The Tcl commands to set up a listener for that condition might look like this:

proc my_listener {{payload ""}} {
    ....
}
pg_listen $db_conn my_listener

The procedure can be defined to accept additional arguments before the payload, with the fixed arguments supplied in the pg_listen command as a single script argument.

proc my_listener2 {command_arg {payload ""}} {
    ....
}
pg_listen $db_conn {my_listener2 Command1}

If the NOTIFY message includes a payload string, Pgtcl will include this as an additional argument to the listener command. If the NOTIFY message does not include a payload string, or includes an empty string as a payload, or you are connected to a pre-9.0.0 PostgreSQL database, then no additional argument will be supplied to the listener command. This is why you need to have an optional argument to your listener command, not a required argument.

Passing a payload string to the notification command was added in pgtclng-1.8.0 and pgintcl-3.2.0, and only works when connected to a PostgreSQL-9.0.0 or higher database server.

Caution

Code written for previous versions of the Pgtcl interfaces should be updated to include an optional argument to all listener callback commands. If you do not update your listener callback command to have an optional argument, and you never include a payload in the notification SQL, your script will not have any problems. However, note that anyone who can connect to the database can send a notification (if they know the channel name used in the pg_listen command), and they can include a payload. If your listener callback does not expect a payload argument, it will throw a background error (which may or may not terminate the script) if it receives such a payload argument.