On 12/09/16 22:21, Andres Freund wrote:
On 2016-09-12 21:57:39 +0200, Petr Jelinek wrote:
On 12/09/16 21:54, Andres Freund wrote:
On 2016-09-12 21:47:08 +0200, Petr Jelinek wrote:
On 09/09/16 06:33, Peter Eisentraut wrote:
The start_replication option pg_version option is not documented and
not used in any later patch. We can probably do without it and just
rely on the protocol version.
That's leftover from binary type data transfer which is not part of this
initial approach as it adds a lot of complications to both protocol and
apply side. So yes can do without.
FWIW, I don't think we can leave this out of the initial protocol
design. We don't have to implement it, but it has to be part of the
design.
I don't think it's a good idea to have unimplemented parts of protocol, we
have protocol version so it can be added in v2 when we have code that is
able to handle it.
I don't think we have to have it part of the protocol. But it has to be
forseen, otherwise introducing it later will end up requiring more
invasive changes than acceptable. I don't want to repeat the "libpq v3
protocol" evolution story here.
Oh sure, I don't see that as big problem, the TupleData already contains
type of the data it sends (to distinguish between nulls and text data)
so that's mostly about adding some different type there and we'll also
need type info in the column part of the Relation message but that
should be easy to fence with one if for different protocol version.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
