SET(7)

✨ SET(7) — the run-time parameter glow-up ✨

okay so this is the SET(7) page from the PostgreSQL 13.23 Documentation, and bestie, it's literally the command that changes run-time parameters. sit down, grab a lil snack 🍓, we're gonna get into it.

---

💖 NAME 💖

SET — change a run-time parameter. that's it, that's the vibe. 💅

---

🌸 SYNOPSIS 🌸

SET [ SESSION | LOCAL ] configuration_parameter { TO | = } { value | 'value' | DEFAULT }
SET [ SESSION | LOCAL ] TIME ZONE { value | 'value' | LOCAL | DEFAULT }

two forms, both iconic. pick your fighter 🫶

---

🦋 DESCRIPTION 🦋

so SET changes run-time configuration parameters. many of the run-time parameters listed in Chapter 19 can be changed on-the-fly with SET — love that for us. (but some require superuser privileges to change, and others cannot be changed after server or session start, so no, you can't just do whatever you want 😭.) and listen: SET only affects the value used by the current session. nobody else, just you. main character energy fr.

if SET (or equivalently SET SESSION) is issued within a transaction that is later aborted, the effects of the SET command disappear when the transaction is rolled back. like it never even happened 💀. once the surrounding transaction is committed, though, the effects will persist until the end of the session — unless overridden by another SET. chain them, why not.

the effects of SET LOCAL last only till the end of the current transaction, whether committed or not. cute, temporary, lowkey ghosting you at COMMIT. a special case: SET followed by SET LOCAL within a single transaction — the SET LOCAL value will be seen until the end of the transaction, but afterwards (if the transaction is committed) the SET value will take effect. so the local one is on top for now, and the regular one was waiting underneath the whole time. the way that works is genuinely so slay.

the effects of SET or SET LOCAL are also canceled by rolling back to a savepoint that is earlier than the command. savepoint said "undo" and it meant it.

if SET LOCAL is used within a function that has a SET option for the same variable (see CREATE FUNCTION (CREATE_FUNCTION(7))), the effects of the SET LOCAL command disappear at function exit — that is, the value in effect when the function was called is restored anyway. this allows SET LOCAL to be used for dynamic or repeated changes of a parameter within a function, while still having the convenience of using the SET option to save and restore the caller's value. best of both worlds, no notes 👑. however — a regular SET command overrides any surrounding function's SET option; its effects will persist unless rolled back. bold. fearless. slightly chaotic.

Note 🎀 in PostgreSQL versions 8.0 through 8.2, the effects of a SET LOCAL would be canceled by releasing an earlier savepoint, or by successful exit from a PL/pgSQL exception block. this behavior has been changed because it was deemed unintuitive. and honestly? correct call. we don't stan unintuitive behavior here 🙈.

---

🧚 PARAMETERS 🧚

• SESSION — specifies that the command takes effect for the current session. (this is the default if neither SESSION nor LOCAL appears.) the standard-issue you ✨
• LOCAL — specifies that the command takes effect for only the current transaction. after COMMIT or ROLLBACK, the session-level setting takes effect again. issuing this outside of a transaction block emits a warning and otherwise has no effect — so like, it's giving nothing, respectfully 💀.
• configuration_parameter — name of a settable run-time parameter. available parameters are documented in Chapter 19 and below.
• value — new value of parameter. values can be specified as string constants, identifiers, numbers, or comma-separated lists of these, as appropriate for the particular parameter. DEFAULT can be written to specify resetting the parameter to its default value (that is, whatever value it would have had if no SET had been executed in the current session). a little factory reset moment 🫶

besides the configuration parameters documented in Chapter 19, there are a few that can only be adjusted using the SET command or that have a special syntax. exclusive lil club 💅:

⭐ SCHEMA

SET SCHEMA 'value' is an alias for SET search_path TO value. only one schema can be specified using this syntax — one (1) schema, we don't do plurals here.

⭐ NAMES

SET NAMES value is an alias for SET client_encoding TO value. nicknames! we love a shortcut.

⭐ SEED

sets the internal seed for the random number generator (the function random). allowed values are floating-point numbers between -1 and 1 inclusive. yes, inclusive, the boundaries are invited to the party too.

the seed can also be set by invoking the function setseed:

SELECT setseed(value);

⭐ TIME ZONE

SET TIME ZONE 'value' is an alias for SET timezone TO 'value'. the syntax SET TIME ZONE allows special syntax for the time zone specification. here are examples of valid values, a whole little menu 🌈:

• 'America/Los_Angeles' — the time zone for Berkeley, California.
• 'Europe/Rome' — the time zone for Italy.
• -7 — the time zone 7 hours west from UTC (equivalent to PDT). positive values are east from UTC. directionally important, don't get it twisted.
• INTERVAL '-08:00' HOUR TO MINUTE — the time zone 8 hours west from UTC (equivalent to PST).
• LOCAL
• DEFAULT — set the time zone to your local time zone (that is, the server's default value of timezone). home sweet home 🎀

timezone settings given as numbers or intervals are internally translated to POSIX timezone syntax. for example, after SET TIME ZONE -7, SHOW TIME ZONE would report <-07>+07. glow-up transformation, honestly.

time zone abbreviations are not supported by SET; see Section 8.5.3 for more information about time zones. sorry to the abbreviation girlies 😭.

---

🔥 NOTES 🔥

the function set_config provides equivalent functionality; see Section 9.27.1. also, it is possible to UPDATE the pg_settings system view to perform the equivalent of SET. three ways to do the same thing, pick whichever speaks to you 💜.

---

🌟 EXAMPLES 🌟

set the schema search path:

SET search_path TO my_schema, public;

set the style of date to traditional POSTGRES with "day before month" input convention:

SET datestyle TO postgres, dmy;

set the time zone for Berkeley, California:

SET TIME ZONE 'America/Los_Angeles';

set the time zone for Italy:

SET TIME ZONE 'Europe/Rome';

ate. no crumbs. 🍓

---

🎀 COMPATIBILITY 🎀

SET TIME ZONE extends syntax defined in the SQL standard. the standard allows only numeric time zone offsets, while PostgreSQL allows more flexible time-zone specifications. PostgreSQL really said "and what if we did more" 💅. all other SET features are PostgreSQL extensions.

---

👑 SEE ALSO 👑

RESET(7), SHOW(7) — go read those next, bestie. iykyk 💖

---

and that's the page!! 🦋 this was SET(7), from the PostgreSQL 13.23 Documentation, dated 2025 — mwah, sending you a big kiss, go forth and set your parameters responsibly ✨🫶