Re: [PATCH] Improve CREATE PUBLICATION error detail for a standalone table/schema name

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: Baji Shaik <baji(dot)pgdev(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Subject: Re: [PATCH] Improve CREATE PUBLICATION error detail for a standalone table/schema name
Date: 2026-10-26 02:38:47
Message-ID: CAHut+PttGqkN0GTNQmAi-k4Rf9fBDnfMSS76=0bkf9aotKiPOQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Baji,

Thanks for the patch. I had a look at the idea and have a few
comments/questions.

On Fri, Oct 23, 2026 at 10:33 AM Baji Shaik <baji(dot)pgdev(at)gmail(dot)com> wrote:
>
> Hi,
>
> If we write any of these, all reasonable guesses at syntax that
> doesn't actually exist:
>
> CREATE PUBLICATION p FOR SEQUENCE s1;
> CREATE PUBLICATION p FOR SCHEMA myschema;
>
> we get this error:
>
> ERROR: invalid publication object list
> DETAIL: One of TABLE or TABLES IN SCHEMA must be specified
> before a standalone table or schema name.
>
> The detail is correct but generic. It doesn't say which name
> triggered it, so when the FOR list has more than one word, there's
> nothing pointing at what to fix.
>

I agree the DETAIL itself is generic, but there is already a "LINE 1:
... ^" caret showing exactly where the parser gave up. What does the
name in the DETAIL give them that the caret does not? Is there a case
where the caret is not enough? If so, it would be good to show it in
the commit message.

> The attached patch adds the name to the message, when the parser has
> one, and a hint listing the valid publication object kinds:
>
> ERROR: invalid publication object list
> DETAIL: One of TABLE or TABLES IN SCHEMA must be specified before
> standalone table or schema name "sequence".
> HINT: Valid publication objects are TABLE, TABLES IN SCHEMA, ALL
> TABLES, and ALL SEQUENCES.
>
> It says "sequence" and not "s1" because SEQUENCE is the word that's
> actually in the wrong position: it's the first word in the FOR list,
> and that's the one missing a TABLE/TABLES IN SCHEMA prefix. s1 is a
> second, separate object in the same list.

Since SEQUENCE is an unreserved keyword, I understand the parser is
treating it as a name here, so "sequence" is technically accurate. But
a user who typed FOR SEQUENCE s1 meant the keyword, and IMO double
quotes normally imply an identifier [1]. Is optimising for the rare
case (a table really named "sequence") worth the potential confusion
in the common one?

> HINT: Valid publication objects are TABLE, TABLES IN SCHEMA, ALL
> TABLES, and ALL SEQUENCES.
>

This HINT is being used more like a summary of the syntax than a hint
about what the user should do [1], but the docs already cover it.
Doing like this will also need to be kept up to date whenever a new
publication object kind is added.

Note that this error message is in common code, so despite the post
$SUBJECT you will get this same message also for ALTER PUBLICATION.
This has caused problems for this message before [2]. Your proposed
HINT won't always make sense for the ALTER case. Try this:

test_pub=# ALTER PUBLICATION pub ADD SEQUENCE s1;
ERROR: invalid publication object list
LINE 1: ALTER PUBLICATION pub ADD SEQUENCE s1;
^
DETAIL: One of TABLE or TABLES IN SCHEMA must be specified before
standalone table or schema name "sequence".
HINT: Valid publication objects are TABLE, TABLES IN SCHEMA, ALL
TABLES, and ALL SEQUENCES.

e.g. the HINT is wrong here because there is no such thing as ALTER
PUBLICATION pub ADD ALL TABLES.

~~~

In summary, FWIW, I felt the existing message is adequate and might be
better left alone. It's not perfect, but I think the caret is doing
the job well enough. The patch HINT in particular introduces new
problems. If you still want to include the name in the DETAIL, then
you might need to address the quoting problem first (e.g. by wording
it so it doesn't look like an identifier), but I'm not sure it's worth
it.

======
[1] https://www.postgresql.org/docs/current/error-style-guide.html
[2] https://www.postgresql.org/message-id/CALDaNm2mcGubJ-iLb7wbMSBt_SfGSpV0UoK_oKMT5VbNLM3uXw%40mail.gmail.com

Kind Regards,
Peter Smith.
Fujitsu Australia

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2026-10-26 02:43:26 Re: Assert failure in try_nestloop_path()
Previous Message Tom Lane 2026-10-26 02:20:04 Let's drop support for named POSIX semaphores