RE: Added schema level support for publication.
| От | houzj.fnst@fujitsu.com |
|---|---|
| Тема | RE: Added schema level support for publication. |
| Дата | |
| Msg-id | OS0PR01MB57163E3432358A7371F0CD9B94D69@OS0PR01MB5716.jpnprd01.prod.outlook.com обсуждение исходный текст |
| Ответ на | Re: Added schema level support for publication. (Amit Kapila <amit.kapila16@gmail.com>) |
| Ответы |
Re: Added schema level support for publication.
|
| Список | pgsql-hackers |
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.
Best regards,
Hou zj
Вложения
В списке pgsql-hackers по дате отправления: