On 2014-09-03 11:23:21 -0400, Robert Haas wrote:
> On Wed, Sep 3, 2014 at 11:06 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> >> >> Maybe:
> >> >>
> >> >> ERROR: pg_logical_slot_peek_changes cannot be used with a plugin that
> >> >> produces only binary output
> >> >> HINT: Use pg_logical_slot_peek_binary_changes instead.
> >> >
> >> > That level has no knowledge of what it's used by, so I think that'd
> >> > require bigger changes than worth it.
> >>
> >> ERROR: this logical decoding plugin can only produce binary output
> >> ERROR: logical decoding plugin "%s" can only produce binary output
> >
> > ERROR: logical decoding plugin "%s" produces binary output, but sink only copes with textual data
> >
> > Not sure about 'sink'. Maybe 'receiving side' or 'receiver'?
> >
> > Not 100% sure if the name is available in that site, but if not it can
> > be left of without hurting much.
>
> I was trying to avoid mentioning the word "sink" because we don't
> actually have a real term for that.
I understand the hesitation. I don't like it either, but I don't think
it gets clearer by leaving it off entirely.
> From the user's perspective, it's
> not going to be obvious that the function they invoked is the sink or
> receiver; to them, it's just an interface - if anything, it's a
> *sender* of the changes to them.
Is 'logical output method' perhaps better? It'd coincide with the terms
in the code and docs too.
> In case I lose that argument, please at least write "allows" instead
> of "copes with"; the latter I think is too informal for an error
> message.
Ok, sure.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services