Re: pgsql: Raise a warning if there is a possibility of data from multiple
От | Amit Kapila |
---|---|
Тема | Re: pgsql: Raise a warning if there is a possibility of data from multiple |
Дата | |
Msg-id | CAA4eK1+5EQZrQff1y-XFU5=GLvZT43cuPPVRhpsTGvvA+Bx-_Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgsql: Raise a warning if there is a possibility of data from multiple (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: pgsql: Raise a warning if there is a possibility of data from multiple
|
Список | pgsql-committers |
On Thu, Sep 8, 2022 at 2:38 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Thu, Sep 8, 2022 at 4:23 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > On Thu, Sep 8, 2022 at 12:22 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > > > > > > Should the tables and the function in this query be schema-qualified? > > > Looking at other code in subscriptioncmd.c, we use schema-qualified > > > names. It works even without the schema names but it may be better to > > > make them consistent. > > > > > > FYI, looking at tablesync.c, there are both styles; it seems that > > > recently added codes use schema-unqualified names. > > > > > > > Yeah, it is better to be consistent in all places and add a schema > > name before accessing an object rather than for one or two places. Do > > we need similar handling for pg_dump code as well, see > > getPublications()? > > We can fix at least getPublications() and getSubscriptions() as well. > I'll make a patch for that. Thanks. > Or do you want to fix all of them, > including non-logical-replication-related ones? > I feel it is better to be consistent across the entire code base unless there is a reason for doing it differently. Does anyone else have any thoughts on this matter? -- With Regards, Amit Kapila.
В списке pgsql-committers по дате отправления: