From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: slotname vs slot_name |
Date: | 2014-06-05 16:33:28 |
Message-ID: | 20140605163328.GR5146@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas wrote:
> > BTW, the stuff that we have in pg_llog are not really logs at all, so
> > pg_llog was always a misnomer.
>
> Also true.
>
> For my part, I'd strongly prefer a name based on the term "logical
> decoding". This feature has lots of names (change-set extraction,
> logical replication, blah blah) and I worked pretty hard to make sure
> that the core patch as committed referred to it in just one way
> (logical decoding) everywhere. I'd rather not call this pg_lcse or
> pg_lcset or something like that because now we're introducing other
> terminology that's not used elsewhere. I'll defer to the group on
> whether it should be called pg_logical or pg_logicaldecoding or
> pg_logical_decoding or pg_ldecoding or pg_logdec or
> pg_lOgIcAl___DECODing, but it should be something somehow based on
> that term.
There is no reason not to use long names, so I think pg_logical_decoding
is fine.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alexey Klyukin | 2014-06-05 16:34:24 | Re: Could not open file pg_multixact/offsets/ ERROR on 9.3.4 |
Previous Message | Greg Stark | 2014-06-05 16:15:58 | Re: performance regression in 9.2/9.3 |