Re: Added schema level support for publication.
vignesh C <vignesh21@gmail.com>
From: vignesh C <vignesh21@gmail.com>
To: "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
Masahiko Sawada <sawada.mshk@gmail.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
Tom Lane <tgl@sss.pgh.pa.us>, Peter Smith <smithpb2250@gmail.com>,
"tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>, Greg Nancarrow <gregn4422@gmail.com>, Ajin Cherian <itsajin@gmail.com>, Rahila Syed <rahilasyed90@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Date: 2021-09-12T15:13:12Z
Lists: pgsql-hackers
Attachments
- v27-0001-Made-the-existing-relation-cache-invalidation-an.patch (text/x-patch) patch v27-0001
- v27-0002-Added-schema-level-support-for-publication.patch (text/x-patch) patch v27-0002
- v27-0003-Client-side-changes-to-support-FOR-ALL-TABLES-IN.patch (text/x-patch) patch v27-0003
- v27-0004-Tests-for-FOR-ALL-TABLES-IN-SCHEMA-publication.patch (text/x-patch) patch v27-0004
- v27-0005-Documentation-for-FOR-ALL-TABLES-IN-SCHEMA-publi.patch (text/x-patch) patch v27-0005
- v27-0006-Implemented-pg_publication_objects-view.patch (text/x-patch) patch v27-0006
On Fri, Sep 10, 2021 at 11:21 AM houzj.fnst@fujitsu.com
<houzj.fnst@fujitsu.com> wrote:
>
> From Friday, September 10, 2021 1:10 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > On Fri, Sep 10, 2021 at 8:54 AM Hou zhijie <houzj.fnst@fujitsu.com> wrote:
> > >
> > > From Friday, September 10, 2021 10:33 AM Hou
> > Zhijie<houzj.fnst@fujitsu.com> wrote:
> > >
> > > Besides, If we don't want to use a new flag to distinguish tablename and
> > schemaname,
> > > We can only check the NodeTag to distinguish the difference.
> > >
> > > Attach two diff patches based on the latest schema patch
> > > which change the code with a flag and without a flag.
> > >
> >
> > I would prefer a version without additional flags unless you think it
> > is difficult to extend it in the future for other objects like
> > sequences which as far as I can see shouldn't be the case.
>
> Ok, I agreed.
>
> > Is there a
> > reason to define pubobj_name similar to any_name? If so, then please
> > do add the comments. One reason I could think of is that any_name is
> > not used for schema names currently which might have motivated you to
> > define a separate naming convention for publication.
>
> When I used any_name, Bison reported that the dot('.') in rule attr
> would have a shift/reduce conflict with the dot('.') in rule indirection_el
> which also used in pubobj_expr. So, I declared a new rule which will directly
> use indirection_el to resolve the conflicts.
>
> Attach the without-flag version and add comments about the pubobj_name.
Thanks for the changes, the suggested changes make the parsing code
simpler. I have merged the changes to the main patch. Attached v27
patch has the changes for the same.
Regards,
Vignesh
Commits
-
Include schema/table publications even with exclude options in dump.
- 4aa6fa3cd0a2 18.0 landed
-
Rename some enums to use TABLE instead of REL.
- b3812d0b9bcf 15.0 landed
-
Add tap tests for the schema publications.
- 6b0f6f79eef2 15.0 landed
-
Allow publishing the tables of schema.
- 5a2832465fd8 15.0 landed
-
In pg_dump, use simplehash.h to look up dumpable objects by OID.
- 92316a4582a5 15.0 cited