On Mon, Sep 23, 2013 at 1:11 PM, Alvaro Herrera <alvhe...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers