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
