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
Ответ на
Список
Дерево обсуждения
pgsql: Raise a warning if there is a possibility of data from multiple Amit Kapila <akapila@postgresql.org>
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 Amit Kapila <amit.kapila16@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 Amit Kapila <amit.kapila16@gmail.com>
Re: pgsql: Raise a warning if there is a possibility of data from multiple Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql: Raise a warning if there is a possibility of data from multiple Amit Kapila <amit.kapila16@gmail.com>
Re: pgsql: Raise a warning if there is a possibility of data from multiple Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql: Raise a warning if there is a possibility of data from multiple vignesh C <vignesh21@gmail.com>
On Thu, Sep 8, 2022 at 2:38 PM Masahiko Sawada  wrote:
>
> On Thu, Sep 8, 2022 at 4:23 PM Amit Kapila  wrote:
> >
> > On Thu, Sep 8, 2022 at 12:22 PM Masahiko Sawada  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 по дате отправления
От: Masahiko Sawada
Дата:
От: Alvaro Herrera
Дата:
FAQ