On 2014-09-03 11:23:21 -0400, Robert Haas wrote: > On Wed, Sep 3, 2014 at 11:06 AM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers