Re: Fix doc bug in logical replication. - Mailing list pgsql-hackers

From Dave Cramer
Subject Re: Fix doc bug in logical replication.
Date
Msg-id CADK3HHKy0PMbsaqLMbA-MZy3v5W4s+XnqNfwiSLkph7i4dTdNg@mail.gmail.com
Whole thread Raw
In response to Re: Fix doc bug in logical replication.  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: Fix doc bug in logical replication.
List pgsql-hackers


On Thu, 27 Jun 2019 at 12:50, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
On Sun, Jun 23, 2019 at 10:26:47PM -0400, Robert Treat wrote:
>On Sun, Jun 23, 2019 at 1:25 PM Peter Eisentraut
><peter.eisentraut@2ndquadrant.com> wrote:
>>
>> On 2019-04-12 19:52, Robert Treat wrote:
>> > It is clear to me that the docs are wrong, but I don't see anything
>> > inherently incorrect about the code itself. Do you have suggestions
>> > for how you would like to see the code comments improved?
>>
>> The question is perhaps whether we want to document that non-matching
>> data types do work.  It happens to work now, but do we always want to
>> guarantee that?  There is talk of a binary mode for example.
>>
>
>Whether we *want* to document that it works, documenting that it
>doesn't work when it does can't be the right answer. If you want to
>couch the language to leave the door open that we may not support this
>the same way in the future I wouldn't be opposed to that, but at this
>point we will have three releases with the current behavior in
>production, so if we decide to change the behavior, it is likely going
>to break certain use cases. That may be ok, but I'd expect a
>documentation update to accompany a change that would cause such a
>breaking change.
>

I agree with that. We have this behavior for quite a bit of time, and
while technically we could change the behavior in the future (using the
"not supported" statement), IMO that'd be pretty annoying move. I always
despised systems that "fix" bugs by documenting that it does not work, and
this is a bit similar.

FWIW I don't quite see why supporting binary mode would change this?
Surely we can't just enable binary mode blindly, there need to be some
sort of checks (alignment, type sizes, ...) with fallback to text mode.
And perhaps support only for built-in types.

The proposed implementation of binary only supports built-in types. 
The subscriber turns it on so presumably it can handle the binary data coming at it.

Dave

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Regression tests vs existing users in an installation
Next
From: Tom Lane
Date:
Subject: Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)