From: | Peter Smith <smithpb2250(at)gmail(dot)com> |
---|---|
To: | vignesh C <vignesh21(at)gmail(dot)com> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: CREATE PUBLICATION with 'publish_generated_columns' parameter specified but unassigned |
Date: | 2025-08-05 06:26:34 |
Message-ID: | CAHut+Pv1qTgbQqiA_o3vNNKGft+bZ=abCLdyC9yhs43E53pLLA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 5, 2025 at 2:28 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Tue, 5 Aug 2025 at 05:35, Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> >
> > Here is a v1 patch, where:
> >
> > - now user gets ERROR if the 'publish_generated_columns' parameter is
> > specified without a value
> > - regression tests are updated
>
> Few comments:
> 1) Generally in other case we throw the following error "option
> requires a parameter" for example:
> postgres=# create subscription sub3 connection 'dbname=postgres
> port=5432' publication pub1 with (synchronous_commit );
> ERROR: synchronous_commit requires a parameter
>
> postgres=# create publication pub1 for all tables with ( publish);
> ERROR: publish requires a parameter
>
> How about keeping it similar here too with below code:
> /*
> * A parameter value is required.
> */
> if (def->arg == NULL)
> ereport(ERROR,
> (errcode(ERRCODE_SYNTAX_ERROR),
> errmsg("%s requires a parameter",
> def->defname)));
>
Hi Vignesh, thanks for the review.
I prefer to use a different message here for the following reasons:
a. I feel "%s requires a parameter" is inconsistent with the docs; "%s
requires a value" would make sense to me.
b. This patch case is not quite the same as other examples using "%s
requires a parameter", because 'publish_generated_columns' is an
*enum* parameter; therefore, we should output the valid values here
too, otherwise the message is not very helpful.
c. The already existing message of this function was very recently
improved by PeterE [1], so I prefer to keep the new message consistent
with that one.
> 2) This gets tested via other publication like testpub4, so this test
> is not required:
> -CREATE PUBLICATION pub3 FOR ALL TABLES WITH (publish_generated_columns);
> +CREATE PUBLICATION pub3 FOR ALL TABLES;
> \dRp+ pub3
> Publication pub3
> Owner | All tables | Inserts | Updates | Deletes
> | Truncates | Generated columns | Via root
> --------------------------+------------+---------+---------+---------+-----------+-------------------+----------
> - regress_publication_user | t | t | t | t
> | t | stored | f
> + regress_publication_user | t | t | t | t
> | t | none | f
> (1 row)
>
OK. removed as suggested.
Kind Regards,
Peter Smith.
Fujitsu Australia
Attachment | Content-Type | Size |
---|---|---|
v2-0001-CREATE-PUBLICATION-gencols-param-with-no-value.patch | application/octet-stream | 4.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2025-08-05 06:33:27 | Re: Dropping publication breaks logical replication |
Previous Message | Chao Li | 2025-08-05 06:24:47 | Re: Raw parse tree is not dumped to log |