Re: Added schema level support for publication. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Added schema level support for publication.
Date
Msg-id 1075092.1629206730@sss.pgh.pa.us
Whole thread Raw
In response to Re: Added schema level support for publication.  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Added schema level support for publication.
List pgsql-hackers
Amit Kapila <amit.kapila16@gmail.com> writes:
> On Tue, Aug 17, 2021 at 6:40 AM Peter Smith <smithpb2250@gmail.com> wrote:
>> On Mon, Aug 16, 2021 at 11:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Abstractly it'd be
>>>
>>> createpub := CREATE PUBLICATION pubname FOR cpitem [, ... ] [ WITH ... ]
>>>
>>> cpitem := ALL TABLES |
>>>     TABLE name |
>>>     ALL TABLES IN SCHEMA name |
>>>     ALL SEQUENCES |
>>>     SEQUENCE name |
>>>     ALL SEQUENCES IN SCHEMA name |
>>>     name
>>>
>>> The grammar output would need some post-analysis to attribute the
>>> right type to bare "name" items, but that doesn't seem difficult.

>> That last bare "name" cpitem. looks like it would permit the following syntax:
>> CREATE PUBLICATION pub FOR a,b,c;
>> Was that intentional?

> I think so.

I had supposed that we could throw an error at the post-processing stage,
or alternatively default to assuming that such names are tables.

Now you could instead make the grammar work like

cpitem := ALL TABLES |
      TABLE name [, ...] |
      ALL TABLES IN SCHEMA name [, ...] |
      ALL SEQUENCES |
      SEQUENCE name [, ...] |
      ALL SEQUENCES IN SCHEMA name [, ...]

which would result in a two-level-list data structure.  I'm not sure
that this is better, as any sort of mistake would result in a very
uninformative generic "syntax error" from Bison.  Errors out of a
post-processing stage could be more specific than that.

(Perhaps, though, we should *document* it like the latter way,
even if the actual implementation is more like the first way.)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Greg Nancarrow
Date:
Subject: Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c)
Next
From: Tom Lane
Date:
Subject: Re: ALTER TYPE vs extension membership (was Re: BUG #17144: Upgrade from v13 to v14 with the cube extension failed)