+
+
Column Lists
+
+ By default, all columns of a published table will be replicated to the
+ appropriate subscribers. The subscriber table must have at least all the
+ columns of the published table. However, if a
+ column list is specified then only the columns named
+ in the list will be replicated. This means the subscriber-side table only
+ needs to have those columns named by the column list. A user might choose to
+ use column lists for behavioral, security or performance reasons.
+
+
+
+
Column List Rules
+
+ A column list is specified per table following the table name, and enclosed
+ by parentheses. See for details.
+
+
+ When specifying a column list, the order of columns is not important. If no
+ column list is specified, all columns of the table are replicated through
+ this publication, including any columns added later. This means a column
+ list which names all columns is not quite the same as having no column list
+ at all. For example, if additional columns are added to the table then only
+ those named columns mentioned in the column list will continue to be
+ replicated.
+
+
+ Column lists have no effect for TRUNCATE command.
+
+
+
+
+
+
Column List Restrictions
+
+ A column list can contain only simple column references.
+
+
+ If a publication publishes UPDATE or
+ DELETE operations, any column list must include the
+ table's replica identity columns (see
+ ).
+ If a publication publishes only INSERT operations, then
+ the column list is arbitrary and may omit some replica identity columns.
+
+
+
+
+
+
Partitioned Tables
+
+ For partitioned tables, the publication parameter
+ publish_via_partition_root determines which column list
+ is used. If publish_via_partition_root is
+ true, the root partitioned table's column list is used.
+ Otherwise, if publish_via_partition_root is
+ false (default), each partition's column list is used.
+
+
+
+
+
+
Initial Data Synchronization
+
+ If the subscription requires copying pre-existing table data and a
+ publication specifies a column list, only data from those columns will be
+ copied.
+
+
+
+ If the subscriber is in a release prior to 15, copy pre-existing data
+ doesn't use column lists even if they are defined in the publication.
+ This is because old releases can only copy the entire table data.
+
+
+
+
+
+
+
Combining Multiple Column Lists
+
+
+ It is not supported to have a subscription comprising several publications
+ where the same table has been published with different column lists.
+ This means changing the column lists of the tables being subscribed could
+ cause inconsistency of column lists among publications, in which case
+ the will be successful but later
+ the walsender on the publisher, or the subscriber may throw an error. In
+ this scenario, the user needs to recreate the subscription after adjusting
+ the column list or drop the problematic publication using
+ ALTER SUBSCRIPTION ... DROP PUBLICATION and then add it
+ back after adjusting the column list.
+
+ Background: The main purpose of the column list feature is to allow
+ statically different table shapes on publisher and subscriber, or hide
+ sensitive column data. In both cases, it doesn't seem to make sense to
+ combine column lists.
+
+
+
+
+
+
+
Examples
+
+ Create a table t1 to be used in the following example.
+test_pub=# CREATE TABLE t1(id int, a text, b text, c text, d text, e text, PRIMARY KEY(id));
+CREATE TABLE
+
+
+ Create a publication p1. A column list is defined for
+ table t1 to reduce the number of columns that will be
+ replicated. Notice that the order of column names in the column list does
+ not matter.
+test_pub=# CREATE PUBLICATION p1 FOR TABLE t1 (id, b, a, d);
+CREATE PUBLICATION
+
+
+ psql can be used to show the column lists (if defined)
+ for each publication.
+test_pub=# \dRp+
+ Publication p1
+ Owner | All tables | Inserts | Updates | Deletes | Truncates | Via root
+----------+------------+---------+---------+---------+-----------+----------
+ postgres | f | t | t | t | t | f
+Tables:
+ "public.t1" (id, a, b, d)
+
+
+ psql can be used to show the column lists (if defined)
+ for each table.
+test_pub=# \d t1
+ Table "public.t1"
+ Column | Type | Collation | Nullable | Default
+--------+---------+-----------+----------+---------
+ id | integer | | not null |
+ a | text | | |
+ b | text | | |
+ c | text | | |
+ d | text | | |
+ e | text | | |
+Indexes:
+ "t1_pkey" PRIMARY KEY, btree (id)
+Publications:
+ "p1" (id, a, b, d)
+
+
+ On the subscriber node, create a table t1 which now
+ only needs a subset of the columns that were on the publisher table
+ t1, and also create the subscription
+ s1 that subscribes to the publication
+ p1.
+test_sub=# CREATE TABLE t1(id int, b text, a text, d text, PRIMARY KEY(id));
+CREATE TABLE
+test_sub=# CREATE SUBSCRIPTION s1
+test_sub-# CONNECTION 'host=localhost dbname=test_pub application_name=s1'
+test_sub-# PUBLICATION p1;
+CREATE SUBSCRIPTION
+
+
+ On the publisher node, insert some rows to table t1.
+test_pub=# INSERT INTO t1 VALUES(1, 'a-1', 'b-1', 'c-1', 'd-1', 'e-1');
+INSERT 0 1
+test_pub=# INSERT INTO t1 VALUES(2, 'a-2', 'b-2', 'c-2', 'd-2', 'e-2');
+INSERT 0 1
+test_pub=# INSERT INTO t1 VALUES(3, 'a-3', 'b-3', 'c-3', 'd-3', 'e-3');
+INSERT 0 1
+test_pub=# SELECT * FROM t1 ORDER BY id;
+ id | a | b | c | d | e
+----+-----+-----+-----+-----+-----
+ 1 | a-1 | b-1 | c-1 | d-1 | e-1
+ 2 | a-2 | b-2 | c-2 | d-2 | e-2
+ 3 | a-3 | b-3 | c-3 | d-3 | e-3
+(3 rows)
+
+
+ Only data from the column list of publication p1 is
+ replicated.
+test_sub=# SELECT * FROM t1 ORDER BY id;
+ id | b | a | d
+----+-----+-----+-----
+ 1 | b-1 | a-1 | d-1
+ 2 | b-2 | a-2 | d-2
+ 3 | b-3 | a-3 | d-3
+(3 rows)
+
+
+
+
+
+
Conflicts
projects / postgresql.git / commitdiff