I really like Craig's explanation of the feature. [Another nice expansion is provided in the docs,](https://www.postgresql.org/docs/10/static/sql-createtrigger.html)

> While transition tables for AFTER triggers are specified using the REFERENCING clause in the standard way, the row variables used in FOR EACH ROW triggers may not be specified in REFERENCING clause. They are available in a manner which is dependent on the language in which the trigger function is written. Some languages effectively behave as though there is a REFERENCING clause containing `OLD ROW AS OLD NEW ROW AS NEW.`

Essentially they make the whole statement's changes available to you, which is super handy. For reference, that looks like this with transitions tables

    REFERENCING OLD TABLE AS oldtable NEW TABLE AS newtable

That said, you can see an [example here](https://www.postgresql.org/docs/10/static/sql-createtrigger.html), and here is one from the [test suite](https://github.com/postgres/postgres/blob/a571c7f661a7b601aafcb12196d004cdb8b8cb23/src/test/regress/sql/plpgsql.sql),

    CREATE TABLE transition_table_base (id int PRIMARY KEY, val text);
    
    CREATE FUNCTION transition_table_base_ins_func()
      RETURNS trigger
      LANGUAGE plpgsql
    AS $$
    DECLARE
      t text;
      l text;
    BEGIN
      t = '';
      FOR l IN EXECUTE
               $q$
                 EXPLAIN (TIMING off, COSTS off, VERBOSE on)
                 SELECT * FROM newtable
               $q$ LOOP
        t = t || l || E'\n';
      END LOOP;
    
      RAISE INFO '%', t;
      RETURN new;
    END;
    $$;
    
    CREATE TRIGGER transition_table_base_ins_trig
      AFTER INSERT ON transition_table_base
      REFERENCING OLD TABLE AS oldtable NEW TABLE AS newtable
      FOR EACH STATEMENT
      EXECUTE PROCEDURE transition_table_base_ins_func();


Some additional notes

1. They're only available on `AFTER` triggers.
2. They take into account things like `ON CONFLICT`.

It's important to point out that **it's not entirely sure to be available in PG 10**. There are lots of [open issues with transition tables](https://wiki.postgresql.org/wiki/PostgreSQL_10_Open_Items#Transition_Tables). Most have patches. There is some infighting which is kind of routine. It seems the heavy lifting was picked up by someone else. The [thread](https://www.postgresql.org/message-id/87h8z1ov57.fsf%40news-spur.riddles.org.uk) indicates that we'll know soon.