SET(7)

💖 SET(7) — the glow-up your session params have been waiting for 💖

okay bestie, welcome to the PostgreSQL 18.6 era, where SET is literally the "change my settings rn" button and it's giving main character energy. this is the page that tells you how to tweak a run-time parameter on the fly. no cap. 🦋

---

✨ SYNOPSIS ✨

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

---

🌸 DESCRIPTION 🌸

so. the SET command changes run-time configuration parameters. periodt. tons of the run-time params listed in Chapter 19 can be changed on-the-fly with SET. 💅

quick reality check tho, because i love you and i want you informed:

• some parameters can only be changed by superusers, and by users who've been granted SET privilege on that parameter.
• there are also parameters that cannot be changed after server or session start. soz.

SET only affects the value used by the current session. that's the whole vibe — it's yours, it's local, it's not leaking anywhere else. ✨

now the transaction lore, because this is where people get caught slipping:

• if SET (or, equivalently, SET SESSION) is issued inside a transaction that later gets aborted, the effects of the SET command disappear when the transaction is rolled back. poof. gone. 🙈
• once the surrounding transaction is committed, the effects stick around until the end of the session — unless something overrides them with another SET.

the effects of SET LOCAL last only till the end of the current transaction, whether that's committed or not. that's its whole deal.

and here's the special case, the plot twist if you will: SET followed by SET LOCAL within a single transaction. in that scenario the SET LOCAL value is what you see until the end of the transaction, but afterwards (if the transaction is committed) the SET value takes effect. iconic behaviour honestly. 👑

also: the effects of SET or SET LOCAL are cancelled by rolling back to a savepoint that's earlier than the command. keep that in your notes app. 📝

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 — meaning the value in effect when the function was called gets restored anyway. this is a feature bestie, it lets you use SET LOCAL for dynamic or repeated changes of a parameter inside a function while still having the convenience of using the SET option to save and restore the caller's value. 🫶

however — and i need you to hear me — a regular SET command overrides any surrounding function's SET option. its effects will persist unless rolled back. no take-backs.

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? they were so right for that.

---

🎀 PARAMETERS 🎀

• SESSION — says the command takes effect for the current session. this is the default if neither SESSION nor LOCAL shows up. it's just here, being chill.
• LOCAL — says the command takes effect for only the current transaction. after COMMIT or ROLLBACK, the session-level setting takes effect again. ⚠️ if you issue this outside of a transaction block, it emits a warning and otherwise has no effect. so, like, do it inside a transaction or don't bother.
• configuration_parameter — the name of a settable run-time parameter. the available parameters are documented in Chapter 19 and below. 📚
• value — the new value of the 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. ✨

---

🌈 the special-syntax squad 🌈

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. meet the crew:

💜 SCHEMA

SET SCHEMA 'value' is an alias for SET search_path TO value. only one schema can be specified using this syntax. one. singular. don't push it.

💜 NAMES

SET NAMES 'value' is an alias for SET client_encoding TO value. cute, short, does the thing.

💜 SEED

sets the internal seed for the random number generator (the function random). allowed values are floating-point numbers between -1 and 1 inclusive. 🎲

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, and yes, every single one slays in its own way:

• '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.
• 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).

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. yes that's a real output, no i will not explain the angle brackets, that's just what it does. 💀

⚠️ time zone abbreviations are not supported by SET; see Section 8.5.3 for more information about time zones. lowercase pdt will not save you here bestie.

---

📝 NOTES 📝

the function set_config provides equivalent functionality — see Section 9.28.1. 🫶

also, it's possible to UPDATE the pg_settings system view to perform the equivalent of SET. yes really. there's always another way.

---

🔥 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';

look at that. four examples. all of them correct. we love to see it. 💅✨

---

🌟 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. so we're built different, respectfully. 🌈

all other SET features are PostgreSQL extensions.

---

👀 SEE ALSO 👀

RESET(7), SHOW(7)

iykyk. go read those next, they're the sibling pages and they ate.

---

and that's the whole page, bestie!! 🎀 this was PostgreSQL 18.6, dated 2026, and you just read the SET(7) manual page top to bottom like a scholar. i'm so proud of you. go change a parameter, you've earned it. 💖✨🦋