pg_synonym

Overview

Release 1.0.0 installs SQL 1.0. Requires PG15+ and superuser installation for event triggers; no preload. Invoker-security views retain target privileges/RLS; manual synonym view edits can break synchronization.

Version

Build

You can build the RPM / DEB packages for pg_synonym using pig build:

pig build pkg pg_synonym         # build RPM / DEB packages

Install

You can install pg_synonym directly. First, make sure the PGDG and PIGSTY repositories are added and enabled:

pig repo add pgsql -u          # Add repo and update cache

Install the extension using pig or apt/yum/dnf:

pig install pg_synonym;          # Install for current active PG version

pig ext install -y pg_synonym -v 18  # PG 18
pig ext install -y pg_synonym -v 17  # PG 17
pig ext install -y pg_synonym -v 16  # PG 16
pig ext install -y pg_synonym -v 15  # PG 15

dnf install -y pg_synonym_18       # PG 18
dnf install -y pg_synonym_17       # PG 17
dnf install -y pg_synonym_16       # PG 16
dnf install -y pg_synonym_15       # PG 15

apt install -y postgresql-18-pg-synonym   # PG 18
apt install -y postgresql-17-pg-synonym   # PG 17
apt install -y postgresql-16-pg-synonym   # PG 16
apt install -y postgresql-15-pg-synonym   # PG 15

Create Extension:

CREATE EXTENSION pg_synonym;

Usage

Sources:

• Official source
• Official source
• Official source

pg_synonym maintains table and view aliases as invoker-security views. Release 1.0.0 installs extension version 1.0; PostgreSQL 15 or later and superuser installation are required. It needs no preload or server restart.

Core Workflow

CREATE EXTENSION pg_synonym;
CREATE SCHEMA app;
CREATE SCHEMA erp;
CREATE TABLE erp.customers (id bigint PRIMARY KEY, name text);
SELECT synonym.create('app.customer', 'erp.customers');
INSERT INTO app.customer VALUES (1, 'Ada');
SELECT * FROM app.customer;
SELECT * FROM synonym.list;

All helpers live in the synonym schema.

Operations and Permissions

synonym.create can register an alias before its target exists; event triggers resolve it later. Target renames follow the object identity, and supported column changes rebuild the alias. synonym.refresh() reconciles aliases manually. synonym.drop removes one, with optional if_exists => true.

Access through an alias still checks target permissions and row security. Creating an alias requires creation rights in its schema and usage rights on the target schema. Removing one requires ownership, role membership or superuser rights.

Boundaries

Targets include ordinary, partitioned and foreign tables, views and materialized views. Aliases to aliases, cross-database objects, functions and sequences are unsupported. Use a query for copying data out; the alias is not a substitute for target DDL or truncation. Merging through a view requires PostgreSQL 17 or later.

Manual changes to an alias view can break synchronization. Dependent views may block destructive target changes, and rebuilding an alias can reset grants applied directly to it. Dropping the extension leaves ordinary alias views behind; plan their cleanup separately.