ALTER_USER_MAPPING(7pg13)

πŸ“¦ version 13.23, in opensuse-leap 16.0

πŸ’… ALTER USER MAPPING (7pg13) β€” the glow-up page for your user mappings

ok so real quick β€” this is the ALTER USER MAPPING page from the PostgreSQL 13.23 docs, and yes bestie it's a whole manual page about changing the definition of a user mapping. Sounds niche? It is. Is it important? Also yes. Let's get into it ✨


🌸 NAME 🌸

ALTER_USER_MAPPING β€” literally just "change the definition of a user mapping." That's the whole assignment, no cap.


πŸŽ€ SYNOPSIS πŸŽ€

ALTER USER MAPPING FOR { user_name | USER | CURRENT_USER | SESSION_USER | PUBLIC }
    SERVER server_name
    OPTIONS ( [ ADD | SET | DROP ] option ['value'] [, ... ] )

Look at that curly-brace situation β€” you gotta pick one of those user things, then name your SERVER, then hand over your OPTIONS. She's a structured queen πŸ‘‘


πŸ¦‹ DESCRIPTION πŸ¦‹

ALTER USER MAPPING changes the definition of a user mapping. That's it. That's the vibe check. πŸ’«

Now for the permission tea β˜• β€” and this part actually matters:

  • The owner of a foreign server can alter user mappings for that server for any user.
  • Also, a user can alter a user mapping for their own user name if USAGE privilege on the server has been granted to the user.

So like… you can't just waltz in and edit random people's mappings. Boundaries, bestie 🫢


✨ PARAMETERS ✨

  • user_name β€” the user name of the mapping. Now, CURRENT_USER and USER both match the name of the current user (yes they're the same thing here, don't @ me). And PUBLIC is the main-character wildcard: it's used to match all present and future user names in the system. Iconic behavior honestly πŸ‘‘
  • server_name β€” the server name of the user mapping. Simple. Gorgeous. No notes. πŸŽ€
  • OPTIONS ( [ ADD | SET | DROP ] option ['value'] [, ... ] ) β€” okay this is where you change options for the user mapping. Key deets:
    • The new options override any previously specified options. Out with the old πŸ”₯
    • ADD, SET, and DROP specify the action to be performed.
    • ADD is assumed if no operation is explicitly specified (she's the default, the main character of the trio).
    • Option names must be unique β€” no duplicates allowed, periodt.
    • Options are also validated by the server's foreign-data wrapper, so like, behave accordingly πŸ’…

πŸ“ EXAMPLES πŸ“

Change the password for user mapping bob, server foo:

ALTER USER MAPPING FOR bob SERVER foo OPTIONS (SET password 'public');

That's the whole flex. One line. SET that password. Bob's got a new one now πŸ’€ (and ngl that password is giving "please change me" but it's literally the doc example, so we're keeping it exactly as-is πŸ™ˆ).


🌈 COMPATIBILITY 🌈

ALTER USER MAPPING conforms to ISO/IEC 9075-9 (SQL/MED). Slay for standards compliance ✨

BUT β€” and there's always a but β€” there is a subtle syntax issue: The standard omits the FOR key word.

Why does PostgreSQL keep FOR? Because both CREATE USER MAPPING and DROP USER MAPPING use FOR in analogous positions, and IBM DB2 (being the other major SQL/MED implementation) also requires it for ALTER USER MAPPING. So PostgreSQL diverges from the standard here in the interest of consistency and interoperability. It's giving "we're doing our own thing, but respectfully" πŸ’–


πŸ’œ SEE ALSO πŸ’œ

Go read the friends of this page, iykyk 🧚


ok that's the whole page, bestie β€” you understood it, you ate it, no crumbs left πŸ’…βœ¨

Sign-off szn: this was PostgreSQL 13.23, dated 2025, brought to you by the fine folks behind the ALTER USER MAPPING(7) page. Take care of your user mappings and they'll take care of you 🫢🌸

πŸ“¦ where this page comes from