Re: Misleading error message in logical decoding for binary plugins

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Misleading error message in logical decoding for binary plugins
Date: 2014-08-30 06:52:26
Message-ID: CAB7nPqQDxcHNEBhG71nL6jDGQji9m=FQEoOKs1_YLBFSts4Zsw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 29, 2014 at 11:15 PM, Andres Freund <andres(at)2ndquadrant(dot)com>
wrote:

> > On top of that, a
> > logical receiver receives data in textual form even if the decoder is
> > marked as binary when getting a message with PQgetCopyData.
>
> I have no idea what you mean by that. The data is sent in the format the
> output plugin writes the data in.
>

Well, that's where we don't understand each other. By reading the docs I
understand that by setting output_type to OUTPUT_PLUGIN_BINARY_OUTPUT, all
the changes generated by an output plugin would be automatically converted
to binary and sent to a client back as binary data, but that's not the
case. For example, when using pg_recvlogical on a slot plugged with
test_decoding, the output received is not changed and remains like that
even when using force-binary:
BEGIN 1000
table public.aa: INSERT: a[integer]:2"
COMMIT 1000
Perhaps I didn't understand the docs well, but this is confusing and it
should be clearly specified to the user that output_type only impacts the
SQL interface with the peek&get functions (as far as I tested). As things
stand now, by reading the docs a user can only know that output_type can be
set as OUTPUT_PLUGIN_BINARY_OUTPUT or OUTPUT_PLUGIN_TEXTUAL_OUTPUT, but
there is nothing about what each value means and how it impacts the output
format, and you need to look at the source code to get that this parameter
is used for some sanity checks, only within the logical functions. That's
not really user-friendly.

Attached is a patch improving the documentation regarding those comments.
Regards,
--
Michael

Attachment Content-Type Size
20140830_logdec_docs_v2.patch text/x-diff 2.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2014-08-30 07:16:01 Re: Per table autovacuum vacuum cost limit behaviour strange
Previous Message Jeff Janes 2014-08-30 06:26:01 COPY and heap_sync