How to use variable settings in trigger functions?

Question

I would like to record the id of a user in the session/transaction, using SET, so I could be able to access it later in a trigger function, using current_setting. Basically, I'm trying option n2 from a very similar ticket posted previously, with the difference that I'm using PG 10.1 .

I've been trying 3 approaches to setting the variable:

• SET local myvars.user_id = 4, thereby setting it locally in the transaction;
• SET myvars.user_id = 4, thereby setting it in the session;
• SELECT set_config('myvars.user_id', '4', false), which depending of the last argument, will be a shortcut for the previous 2 options.

None of them is usable in the trigger, which receives NULL when getting the variable through current_setting. Here is a script I've devised to troubleshoot it (can be easily used with the postgres docker image):

database=$POSTGRES_DB
user=$POSTGRES_USER
[ -z "$user" ] && user="postgres"

psql -v ON_ERROR_STOP=1 --username "$user" $database <<-EOSQL
    DROP TRIGGER IF EXISTS add_transition1 ON houses;
    CREATE TABLE IF NOT EXISTS houses (
        id SERIAL NOT NULL,
        name VARCHAR(80),
        created_at TIMESTAMP WITHOUT TIME ZONE DEFAULT now(),
        PRIMARY KEY(id)
    );

    CREATE TABLE IF NOT EXISTS transitions1 (
        id SERIAL NOT NULL,
        house_id INTEGER,
        user_id INTEGER,
        created_at TIMESTAMP WITHOUT TIME ZONE DEFAULT now(),
        PRIMARY KEY(id),
        FOREIGN KEY(house_id) REFERENCES houses (id) ON DELETE CASCADE

    );

    CREATE OR REPLACE FUNCTION add_transition1() RETURNS TRIGGER AS \$\$
        DECLARE
            user_id integer;
        BEGIN
            user_id := current_setting('myvars.user_id')::integer || NULL;
            INSERT INTO transitions1 (user_id, house_id) VALUES (user_id, NEW.id);
            RETURN NULL;
        END;
    \$\$ LANGUAGE plpgsql;

    CREATE TRIGGER add_transition1 AFTER INSERT OR UPDATE ON houses FOR EACH ROW EXECUTE PROCEDURE add_transition1();

    BEGIN;
    %1% SELECT current_setting('myvars.user_id');
    %2% SELECT set_config('myvars.user_id', '55', false);
    %3% SELECT current_setting('myvars.user_id');
    INSERT INTO houses (name) VALUES ('HOUSE PARTY') RETURNING houses.id;
    SELECT * from houses;
    SELECT * from transitions1;
    COMMIT;
    DROP TRIGGER IF EXISTS add_transition1 ON houses;
    DROP FUNCTION IF EXISTS add_transition1;
    DROP TABLE transitions1;
        DROP TABLE houses;
EOSQL

The conclusion I came to was that the function is triggered in a different transaction and a different (?) session. Is this something that one can configure, so that all happens within the same context?

Answer 1

Handle all possible cases for the customized option properly:

1. option not set yet

All references to it raise an exception, including current_setting() unless called with the second parameter missing_ok. The manual:

If there is no setting named setting_name, current_setting throws an error unless missing_ok is supplied and is true.

2. option set to a valid integer literal

3. option set to an invalid integer literal

4. option reset (which burns down to a special case of 3.)

For instance, if you set a customized option with SET LOCAL or set_config('myvars.user_id3', '55', true), the option value is reset at the end of the transaction. It still exists, can be referenced, but it returns an empty string now ('') - which cannot be cast to integer.

Obvious mistakes in your demo aside, you need to prepare for all 4 cases. So:

CREATE OR REPLACE FUNCTION add_transition1()
  RETURNS trigger
  LANGUAGE plpgsql AS
$func$
DECLARE
   _user_id text := current_setting('myvars.user_id', true);  -- see 1.
BEGIN
   IF _user_id ~ '^\d+$' THEN  -- one or more digits?
      INSERT INTO transitions1 (user_id, house_id)
      VALUES (_user_id::int, NEW.id);  -- valid int, cast is safe
   ELSE
      INSERT INTO transitions1 (user_id, house_id)
      VALUES (null, NEW.id);           -- use null instead

      RAISE WARNING 'Invalid user_id % for house_id % was reset to null!'
                  , quote_literal(_user_id), NEW.id;  -- optional
   END IF;

   RETURN NULL;  -- OK for AFTER trigger
END
$func$;

db<>fiddle here

Notes:

• Avoid variable names matching column names. Very error prone. One popular naming convention is to prepend variable names with an underscore: _user_id.

• Assign at declaration time to save another assignment. Note the data type text. We'll cast later, after sorting out invalid input.

• Avoid raising / trapping an exception if possible. The manual:

  A block containing an EXCEPTION clause is significantly more expensive to enter and exit than a block without one. Therefore, don't use EXCEPTION without need.

• Test for valid integer strings. This simple regular expression allows only digits (no leading sign, no white space): _user_id ~ '^\d+$'. I reset to null for any invalid input. Adapt to your needs.

• I added an optional WARNING for your debugging convenience.

• Cases 3. and 4. only arise because customized options are string literals (type text), valid data types cannot be enforced automatically.

Related:

• User defined variables in PostgreSQL
• Is there a way to define a named constant in a PostgreSQL query?

All that aside, there may be more elegant solutions for what you are trying to do without customized options, depending on your exact requirements. Maybe this:

• Fastest way to get current user's OID in Postgres?