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

From Peter Smith
Subject Re: Added schema level support for publication.
Date
Msg-id CAHut+PuCUPkM22k1L-9Wu8ad=kzEQguzWK4uKPJdnRt3oN5SnQ@mail.gmail.com
Whole thread Raw
In response to Re: Added schema level support for publication.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Added schema level support for publication.
List pgsql-hackers
On Mon, Aug 16, 2021 at 11:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Peter Smith <smithpb2250@gmail.com> writes:
> > Then the question from Peter E. [2] "Why can't I have a publication
> > that publishes tables t1, t2, t3, *and* schemas s1, s2, s3." would
> > have an intuitive solution like:
>
> > CREATE PUBLICATION pub1
> > FOR TABLE t1,t2,t3 AND
> > FOR ALL TABLES IN SCHEMA s1,s2,s3;
>
> That seems a bit awkward, since the existing precedent is
> to use commas.  We shouldn't need more than one FOR noise-word,
> either.  So I was imagining syntax more like, say,

When I wrote that "AND" suggestion I had in mind that commas may get
weird if there were objects with keyword names. e.g. if there was a
schema called SEQUENCE and a SEQUENCE called  SEQUENCE then this will
be allowed.

CREATE PUBLICATION pub1 FOR ALL TABLES IN SCHEMA SEQUENCE, SEQUENCE SEQUENCE;

But probably I was just overthinking it.

>
>         CREATE PUBLICATION pub1 FOR
>           TABLE t1,t2,t3, ALL TABLES IN SCHEMA s1,s2,
>           SEQUENCE seq1,seq2, ALL SEQUENCES IN SCHEMA s3,s4;
>
> 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?

------
Kind Regards,
Peter Smith.
Fujitsu Australia.



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: The Free Space Map: Problems and Opportunities
Next
From: Michael Paquier
Date:
Subject: Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode