On Fri, Aug 29, 2014 at 11:15 PM, Andres Freund <and...@2ndquadrant.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
diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index e6880d0..1472a6c 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -403,9 +403,17 @@ typedef struct OutputPluginOptions
OutputPluginOutputType output_type;
} OutputPluginOptions;
</programlisting>
- <literal>output_type</literal> has to either be set to
- <literal>OUTPUT_PLUGIN_TEXTUAL_OUTPUT</literal>
- or <literal>OUTPUT_PLUGIN_BINARY_OUTPUT</literal>.
+ <literal>output_type</literal> is the parameter defining the output
+ format of plugin; it can be one of
+ <literal>OUTPUT_PLUGIN_TEXTUAL_OUTPUT</literal> (support for output
+ format as text) and <literal>OUTPUT_PLUGIN_BINARY_OUTPUT</literal>
+ (support for format output as binary). This parameter influences only
+ the way output changes can be accessed by the set of SQL functions able
+ to query a replication slot. For example, the changes fetched by
+ <xref linkend="app-pgrecvlogical"> are not impacted by this parameter
+ and remain the same, while <function>pg_logical_slot_get_changes</>
+ is not able to query changes using output type
+ <literal>OUTPUT_PLUGIN_BINARY_OUTPUT</literal>.
</para>
<para>
The startup callback should validate the options present in
diff --git a/src/backend/replication/logical/logicalfuncs.c b/src/backend/replication/logical/logicalfuncs.c
index a3a58e6..4f802ad 100644
--- a/src/backend/replication/logical/logicalfuncs.c
+++ b/src/backend/replication/logical/logicalfuncs.c
@@ -394,14 +394,14 @@ pg_logical_slot_get_changes_guts(FunctionCallInfo fcinfo, bool confirm, bool bin
MemoryContextSwitchTo(oldcontext);
/*
- * Check whether the output pluggin writes textual output if that's
+ * Check whether the output plugin writes textual output if that's
* what we need.
*/
if (!binary &&
ctx->options.output_type != OUTPUT_PLUGIN_TEXTUAL_OUTPUT)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
- errmsg("output plugin cannot produce binary output")));
+ errmsg("output plugin produces binary output but only textual output is accepted")))
ctx->output_writer_private = p;
diff --git a/src/include/catalog/objectaccess.h b/src/include/catalog/objectaccess.h
index 4fdd056..1e1cb13 100644
--- a/src/include/catalog/objectaccess.h
+++ b/src/include/catalog/objectaccess.h
@@ -13,7 +13,7 @@
/*
* Object access hooks are intended to be called just before or just after
* performing certain actions on a SQL object. This is intended as
- * infrastructure for security or logging pluggins.
+ * infrastructure for security or logging plugins.
*
* OAT_POST_CREATE should be invoked just after the object is created.
* Typically, this is done after inserting the primary catalog records and
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
