On Mon, Oct 26, 2026 at 9:08 AM shveta malik <[email protected]> wrote: > > On Sat, Oct 24, 2026 at 11:42 AM Amit Kapila <[email protected]> wrote: > > > > The current use of the "datestyle" and other GUCs in libpqwalreceiver > > or in other places is to keep the format portable across nodes but > > here the CLT output will be usually human-readable. So, the same > > analogy doesn't follow here. I am not convinced that this required > > mid-way changing the GUCs temporarily. I feel we can document this > > column and if we still get a request from field for portability of > > this field(s) then we can consider using GUCs to make the format > > consistent. > > > > But it causes ambiguous results as shown in [1]. I am not sure how > documentation will help here. As I see it, the stored key must > convert back to the original value, not to some other value, > especially since the patch’s own docs recommend casting it back to the > column type before comparing. And I don’t think libpqwalreceiver does > this for portability: its comment says it forces these GUCs so values > are output “in a form that is unambiguous to the subscriber.” IMO, > that’s the same goal here: avoiding a wrong stored value, not > portability. >
That is a cross-node compatibility case and similarly pg_dump's output could be restored on another node. I feel if a user changes the datestyle or similar settings in-between different conflict-insertions the results can change accordingly. We shouldn't take such guarantees. It should be documented somewhere along with the following text [1], we can probably give a small example as well. [1] + <para> + The apply worker's <xref linkend="guc-bytea-output"/> and + <xref linkend="guc-quote-all-identifiers"/> settings change how a value + is written without changing the value itself. If these settings differ + between conflicts, the same key can be recorded in different but + equivalent forms, and comparing the recorded text may miss some of them. -- With Regards, Amit Kapila.
