Re: logical changeset generation v6

On Mon, Sep 23, 2013 at 1:11 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> Andres Freund escribió:
>> On 2013-09-23 13:47:05 -0300, Alvaro Herrera wrote:
>
>> > I had proposed pg_recvlogical
>>
>> I still find it wierd/inconsistent to have:
>> * pg_receivexlog
>> * pg_recvlogical
>> binaries, even from the same source directory. Why once "pg_recv" and
>> once "pg_receive"?
>
> Well. What are the principles we want to follow when choosing a name?
> Is consistency the first and foremost consideration? To me, that names
> are exactly consistent is not all that relevant; I prefer a shorter name
> if it embodies all it means. For that reason I didn't like the
> "receiveloglog" suggestion: it's not clear what are the two "log" bits.
> To me this suggests that "logical" should not be shortened. But the
> "recv" thing is clear to be "receive", isn't it? Enough that it can be
> shortened without loss of meaning.
>
> If we consider consistency in naming of tools is uber-important, well,
> obviously my proposal is dead.

What exactly is the purpose of this tool? My impression is that the
"output" of logical replication is a series of function calls to a
logical replication plugin, but does that plugin necessarily have to
produce an output format that gets streamed to a client via a tool
like this? For example, for replication, I'd think you might want the
plugin to connect to a remote database and directly shove the data in;
for materialized views, we might like to push the changes into delta
relations within the source database. In either case, there's no
particular need for any sort of client at all, and in fact it would be
much better if none were required. The existence of a tool like
pg_receivellog seems to presuppose that the goal is spit out logical
change records as text, but I'm not sure that's actually going to be a
very common thing to want to do...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company