It is easy for someone who is new to PostgreSQL and who uses PostgreSQL’s terminal editor psql to confuse the commands
SET. This post contrasts these commands and provides a brief overview of other commands that include the word “set”.
The easiest way to remember how to differentiate
SET is to keep in mind that the “backslash commands” such as
\set are “meta commands” for the command-line psql tool and do not mean anything to the PostgreSQL database itself. The
SET command, which lacks a backslash, is a PostgreSQL database command that happens to be executed against the database from the psql command-line client.
(or other case-insensitive variation1)
|psql terminal editor configuration meta command
(interactive client terminal configuration)
|PostgreSQL database configuration command
|Ends with Semicolon?
|Command Case Sensitive?
(must be exactly
|Parameter/Variable Case Sensitive?
|How are Settings Displayed?
SHOW ALL; or
\set AUTOCOMMIT on
SET search_path TO myschema, public;
There are two more psql meta commands that that “set” things and include the name “set”. The
\pset met command configures how psql presents “query result tables.” Like
\pset can be specified without argument to see all of the current presentation settings.
Unlike the psql meta commands
\gset psql metacommand does affect the PostgreSQL server because
\gset submits the query buffer to the server and then stores the output returned from the server into specified psql variables. I discussed
\gset with a few additional details in the blog post “Setting PostgreSQL psql Variable Based Upon Query Result.”
SET can be used to set variables, the easiest way to distinguish between them is to consider that the backslash commands such as
\set are psql commands (and so
\pset sets variables in the psql client tool) and commands without the backslash such as
SET are PostgreSQL commands sent to the server from psql or from any other client (but ultimately set variables on the server).
Opinions expressed by System Code Geeks contributors are their own.