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 по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: pgsql: Raise a warning if there is a possibility of data from multiple
Следующее
От: Alvaro Herrera
Дата:
Сообщение: pgsql: Fix perltidy breaking perlcritic