CREATE PUBLICATION with 'publish_generated_columns' parameter specified but unassigned

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: CREATE PUBLICATION with 'publish_generated_columns' parameter specified but unassigned
Date: 2025-08-04 06:23:36
Message-ID: CAHut+PsCUCWiEKmB10DxhoPfXbF6jw5RD9ib2LuaQeA_XraW7w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Recently, I learned it is possible to say:

CREATE PUBLICATION pub ... WITH (publish_generated_columns);

This is equivalent to:
CREATE PUBLICATION pub ... WITH (publish_generated_columns = stored);

~~~

Example:

postgres=# create publication pub for table t with
(publish_generated_columns=xxx);
ERROR: invalid value for publication parameter
"publish_generated_columns": "xxx"
DETAIL: Valid values are "none" and "stored".
postgres=# create publication pub for table t with (publish_generated_columns);
CREATE PUBLICATION
postgres=# \dRp pub
List of publications
Name | Owner | All tables | Inserts | Updates | Deletes | Truncates
| Generated columns | Via root
------+----------+------------+---------+---------+---------+-----------+-------------------+----------
pub | postgres | f | t | t | t | t
| stored | f
(1 row)

~~~

However, I could not find this kind of shorthand specification (having
no assigned value) mentioned anywhere in the PG docs [1].

OTOH, I did see this is being tested/commented in 'publication.sql'
[2], so perhaps that means it is deliberate?

~~~

What is the verdict for this syntax -- ok or not?

a- Is it some deliberate, undocumented shorthand?

b- Is it just a documentation omission?

c- Is this an unintended quirk? IIRC, this parameter was initially
Boolean during development, before it was changed to an enum. Maybe
this behaviour/test is an accidental hangover from then?

======
[1] https://www.postgresql.org/docs/devel/sql-createpublication.html
[2] https://github.com/postgres/postgres/blob/master/src/test/regress/sql/publication.sql#L1193

Kind Regards,
Peter Smith.
Fujitsu Australia

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2025-08-04 06:34:41 Re: Potential deadlock in pgaio_io_wait()
Previous Message Naga Appani 2025-08-04 06:16:30 Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring