On Thu, Sep 18, 2014 at 2:18 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> The point is that operating with byteas on SQL level is freaking
> painful.
An example perhaps? I fail to see why it is related to the fact that a
user could simply use that to fetch changes in bytea from a slot:
select data::bytea from pg_logical_slot_get_changes('foo', NULL, NULL);
That's perhaps not more simple than using the binary functions, which
actually explain their existence because of the textual/binary format
context with OUTPUT_PLUGIN_*, but that's possible. It is as well
possible to pay quite a lot with custom data types and casts to
transform textual changes (not to mention that a plugin could send out
bytea changes by itself through the COPY string). Looking at the code,
the only difference between textual and binary is an assertion check
using the database encoding, something unlikely to be triggered on
production systems btw.
>> I am raising this point before the 9.4 ship sails, thinking long-term
>> and to faciliate the maintenance of existing code. Attached is a patch
>> that simplifies the current logical decoding API regarding that.
>
> Sorry, -1.
>
> Improving the docs here is on my roadmap, but I don't see the benefit of
> this.
Well, there is no actual benefit. That's only a logical reasoning to
keep the interface as simple as possible without impacting the feature
range. Enforcing an option with arbitrary values that only has effect
for non-replication connections is unintuitive for a plugin structure
that is dedicated for both non-replication and replication protocols
(using replication protocol offers more flexibility, so I'd expect it
to be more widely used than the SQL interface btw). If docs are
improved, it should at least be clearly stated what is the benefit of
one value to the other when fetching changes using the get/peek
functions.
--
Michael
