Re: Fix doc bug in logical replication.

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: Robert Treat <rob(at)xzilla(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix doc bug in logical replication.
Date: 2019-06-27 17:46:47
Message-ID: CADK3HHKy0PMbsaqLMbA-MZy3v5W4s+XnqNfwiSLkph7i4dTdNg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 27 Jun 2019 at 12:50, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)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(dot)eisentraut(at)2ndquadrant(dot)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

>
>

In response to

Responses

Browse pgsql-hackers by date

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