Re: [Bug] Logical Replication failing if the DateStyle is different in Publisher & Subscriber

On Fri, Oct 22, 2021 at 8:07 AM Japin Li <japinli@hotmail.com> wrote:
>
>
> On Fri, 22 Oct 2021 at 08:26, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > On Thu, Oct 21, 2021 at 11:18 PM Japin Li <japinli@hotmail.com> wrote:
> >>
> >> How it breaks?
> >
> > I don't know the real case but for example, if an application gets
> > changes via pg_recvlogical with a decoding plugin (say wal2json) from
> > the database whose DateStyle setting is "SQL, MDY", it expects that
> > the date values in the streamed data are in the style of "ISO, MDY".
> > But with this change, it will get date values in the style of "ISO"
> > which could lead to a parse error in the application.
> >
> >>  The user also can specify the "options" to get date data
> >> in the style which they are wanted. Right?
> >
> > Right. But doesn't it mean breaking the compatibility?
> >
>
> Yeah, it might be break the compatibility.
>
> In conclusion, this bug has two ways to fix.
>
> In conclusion, this bug has two ways to fix.
>
> 1. Set the parameters on publisher, this might be break the compatibility.

Is it not possible to set the parameter on publisher as "ISO, MDY" or
"ISO, YMD", instead of only "ISO"?
DateStyle includes both, so we may set the parameter with date format...

> 2. Set the parameters on subscriber. In my first patch, I try to set the
>    parameters after establish the connection, it will lead more network
>    round trips. We can set the parameters when connecting the walsender
>    using "options".
>
> For the second way, should we set the parameters same as subscriber or
> use the parameters (e.g. datestyle = "ISO") likes postgres_fdw
> set_transmission_modes()?
>
> Any thoughts?

IMO, setting the parameter value same as the subscriber is better. It
is always possible that we can set any datestyle in the plugins
itself...


Thanks & Regards
SadhuPrasad
EnterpriseDB: http://www.enterprisedb.com