slotname vs slot_name
Hi,
Due to the opened window of the pg_control/catalog version bump a chance
has opened to fix a inconsistency I've recently been pointed
towards:
Namely that replication slots are named 'slot_name' in one half of the
cases and 'slotname' in the other. That's in views, SRF columns,
function parameters and the primary_slotname recovery.conf parameter.
My personal tendency would be to make it slot_name everywhere except the
primary_slotname recovery.conf parameter. There we already have
precedent for shortening names.
Other opinions?
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
On Thu, Jun 5, 2014 at 8:24 AM, Andres Freund <andres@2ndquadrant.com> wrote:
Hi,
Due to the opened window of the pg_control/catalog version bump a chance
has opened to fix a inconsistency I've recently been pointed
towards:
Namely that replication slots are named 'slot_name' in one half of the
cases and 'slotname' in the other. That's in views, SRF columns,
function parameters and the primary_slotname recovery.conf parameter.My personal tendency would be to make it slot_name everywhere except the
primary_slotname recovery.conf parameter. There we already have
precedent for shortening names.Other opinions?
I like using "slot_name" everywhere, i.e, even in recovery.conf.
primary_slot_name seems not so long name.
BTW, what about also renaming pg_llog directory? I'm afraid that
a user can confuse pg_log with pg_llog.
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
On Thu, Jun 5, 2014 at 10:57 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
I like using "slot_name" everywhere, i.e, even in recovery.conf.
primary_slot_name seems not so long name.BTW, what about also renaming pg_llog directory? I'm afraid that
a user can confuse pg_log with pg_llog.
Recently I came across this while tab-completing pg_log ;-)
I remember asking to document pg_llog elsewhere.
--
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 06/05/2014 05:09 AM, Amit Langote wrote:
Hi,
On Thu, Jun 5, 2014 at 10:57 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
I like using "slot_name" everywhere, i.e, even in recovery.conf.
primary_slot_name seems not so long name.BTW, what about also renaming pg_llog directory? I'm afraid that
a user can confuse pg_log with pg_llog.Recently I came across this while tab-completing pg_log ;-)
I remember asking to document pg_llog elsewhere.
+1 for renaming pg_llog. We have all heard the stories of people
deleting pg_clog because "it's just logs". I feel that pg_llog might be
an even greater risk at that (although the consequences are not as
serious as deleting pg_clog.
pg_ldecoding ?
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 05/06/14 10:11, Heikki Linnakangas wrote:
On 06/05/2014 05:09 AM, Amit Langote wrote:
Hi,
On Thu, Jun 5, 2014 at 10:57 AM, Fujii Masao <masao.fujii@gmail.com>
wrote:I like using "slot_name" everywhere, i.e, even in recovery.conf.
primary_slot_name seems not so long name.
+1
BTW, what about also renaming pg_llog directory? I'm afraid that
a user can confuse pg_log with pg_llog.Recently I came across this while tab-completing pg_log ;-)
I remember asking to document pg_llog elsewhere.+1 for renaming pg_llog. We have all heard the stories of people
deleting pg_clog because "it's just logs". I feel that pg_llog might be
an even greater risk at that (although the consequences are not as
serious as deleting pg_clog.pg_ldecoding ?
pg_lcse or pg_lcset ?
--
Petr Jelinek 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
Hi,
On Thu, 2014-06-05 at 10:57 +0900, Fujii Masao wrote:
BTW, what about also renaming pg_llog directory? I'm afraid that
a user can confuse pg_log with pg_llog.
+1. I hit this while testing 9.4 this week. Should be confusing for many
end-users.
Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR
On Jun 5, 2014 10:22 AM, "Devrim Gündüz" <devrim@gunduz.org> wrote:
Hi,
On Thu, 2014-06-05 at 10:57 +0900, Fujii Masao wrote:
BTW, what about also renaming pg_llog directory? I'm afraid that
a user can confuse pg_log with pg_llog.+1. I hit this while testing 9.4 this week. Should be confusing for many
end-users.
+500. We already have two directories that users remove to get free space
thinking it's safe because it's just log files. We don't need one more :-)
/Magnus
On Thu, Jun 5, 2014 at 5:27 PM, Magnus Hagander <magnus@hagander.net> wrote:
On Jun 5, 2014 10:22 AM, "Devrim Gündüz" <devrim@gunduz.org> wrote:
Hi,
On Thu, 2014-06-05 at 10:57 +0900, Fujii Masao wrote:
BTW, what about also renaming pg_llog directory? I'm afraid that
a user can confuse pg_log with pg_llog.+1. I hit this while testing 9.4 this week. Should be confusing for many
end-users.+500. We already have two directories that users remove to get free space
thinking it's safe because it's just log files. We don't need one more :-)
Adding a +1 on top of this already-huge stack.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2014-06-05 10:57:58 +0900, Fujii Masao wrote:
On Thu, Jun 5, 2014 at 8:24 AM, Andres Freund <andres@2ndquadrant.com> wrote:
Hi,
Due to the opened window of the pg_control/catalog version bump a chance
has opened to fix a inconsistency I've recently been pointed
towards:
Namely that replication slots are named 'slot_name' in one half of the
cases and 'slotname' in the other. That's in views, SRF columns,
function parameters and the primary_slotname recovery.conf parameter.My personal tendency would be to make it slot_name everywhere except the
primary_slotname recovery.conf parameter. There we already have
precedent for shortening names.Other opinions?
I like using "slot_name" everywhere, i.e, even in recovery.conf.
primary_slot_name seems not so long name.
It also has the advantage that we can add a couple more slot_* options
later. Will do that.
BTW, what about also renaming pg_llog directory? I'm afraid that
a user can confuse pg_log with pg_llog.
We have:
* pg_ldecoding (Heikki)
* pg_lcse or pg_lcset (Petr)
* pg_logical (Andres)
I like, what a surprise, my own suggestion best. The name seems more
versatile because it's not restricted to decoding.
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
On Thu, Jun 5, 2014 at 7:57 PM, Andres Freund <andres@2ndquadrant.com> wrote:
We have:
* pg_ldecoding (Heikki)
* pg_lcse or pg_lcset (Petr)
* pg_logical (Andres)
pg_decoding, simply?
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2014-06-05 20:02:38 +0900, Michael Paquier wrote:
On Thu, Jun 5, 2014 at 7:57 PM, Andres Freund <andres@2ndquadrant.com> wrote:
We have:
* pg_ldecoding (Heikki)
* pg_lcse or pg_lcset (Petr)
* pg_logical (Andres)pg_decoding, simply?
I don't like it much, because it's pretty much restricted for data used
during decoding. So we'll potentially need a different directory for related
features (replication identifiers, apply, ...).
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
On Thu, Jun 5, 2014 at 12:57 PM, Andres Freund <andres@2ndquadrant.com>
wrote:
On 2014-06-05 10:57:58 +0900, Fujii Masao wrote:
On Thu, Jun 5, 2014 at 8:24 AM, Andres Freund <andres@2ndquadrant.com>
wrote:
Hi,
Due to the opened window of the pg_control/catalog version bump a
chance
has opened to fix a inconsistency I've recently been pointed
towards:
Namely that replication slots are named 'slot_name' in one half of the
cases and 'slotname' in the other. That's in views, SRF columns,
function parameters and the primary_slotname recovery.conf parameter.My personal tendency would be to make it slot_name everywhere except
the
primary_slotname recovery.conf parameter. There we already have
precedent for shortening names.Other opinions?
I like using "slot_name" everywhere, i.e, even in recovery.conf.
primary_slot_name seems not so long name.It also has the advantage that we can add a couple more slot_* options
later. Will do that.BTW, what about also renaming pg_llog directory? I'm afraid that
a user can confuse pg_log with pg_llog.We have:
* pg_ldecoding (Heikki)
* pg_lcse or pg_lcset (Petr)
* pg_logical (Andres)I like, what a surprise, my own suggestion best. The name seems more
versatile because it's not restricted to decoding.
I don't care too much really, either one is find - but if I should vote,
I'll split my vote between pg_locical and pg_ldecoding, I don't like lcse
and lcset very much.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On 06/05/2014 01:57 PM, Andres Freund wrote:
On 2014-06-05 10:57:58 +0900, Fujii Masao wrote:
On Thu, Jun 5, 2014 at 8:24 AM, Andres Freund <andres@2ndquadrant.com> wrote:
Hi,
Due to the opened window of the pg_control/catalog version bump a chance
has opened to fix a inconsistency I've recently been pointed
towards:
Namely that replication slots are named 'slot_name' in one half of the
cases and 'slotname' in the other. That's in views, SRF columns,
function parameters and the primary_slotname recovery.conf parameter.My personal tendency would be to make it slot_name everywhere except the
primary_slotname recovery.conf parameter. There we already have
precedent for shortening names.Other opinions?
I like using "slot_name" everywhere, i.e, even in recovery.conf.
primary_slot_name seems not so long name.It also has the advantage that we can add a couple more slot_* options
later. Will do that.BTW, what about also renaming pg_llog directory? I'm afraid that
a user can confuse pg_log with pg_llog.We have:
* pg_ldecoding (Heikki)
* pg_lcse or pg_lcset (Petr)
* pg_logical (Andres)I like, what a surprise, my own suggestion best. The name seems more
versatile because it's not restricted to decoding.
The problem with pg_logical is that it's not restricted to much at all
;-), "logical" is an awfully generic name.
BTW, the stuff that we have in pg_llog are not really logs at all, so
pg_llog was always a misnomer.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 06/05/2014 02:10 PM, Magnus Hagander wrote:
On Thu, Jun 5, 2014 at 12:57 PM, Andres Freund <andres@2ndquadrant.com>
wrote:We have:
* pg_ldecoding (Heikki)
* pg_lcse or pg_lcset (Petr)
* pg_logical (Andres)I like, what a surprise, my own suggestion best. The name seems more
versatile because it's not restricted to decoding.I don't care too much really, either one is find - but if I should vote,
I'll split my vote between pg_locical and pg_ldecoding, I don't like lcse
and lcset very much.
pg_changesets ?
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2014-06-05 14:12:31 +0300, Heikki Linnakangas wrote:
On 06/05/2014 01:57 PM, Andres Freund wrote:
On 2014-06-05 10:57:58 +0900, Fujii Masao wrote:
We have:
* pg_ldecoding (Heikki)
* pg_lcse or pg_lcset (Petr)
* pg_logical (Andres)I like, what a surprise, my own suggestion best. The name seems more
versatile because it's not restricted to decoding.The problem with pg_logical is that it's not restricted to much at all ;-),
"logical" is an awfully generic name.
So is base/, global/, pg_stat/,... I don't think we need
uber-descriptive names here. I do think it's descriptive enough that
unrelated data won't be looked for in there. And imo that's the case.
BTW, the stuff that we have in pg_llog are not really logs at all, so
pg_llog was always a misnomer.
I'm not fighting for it :).
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
On 2014-06-05 12:57:57 +0200, Andres Freund wrote:
On 2014-06-05 10:57:58 +0900, Fujii Masao wrote:
I like using "slot_name" everywhere, i.e, even in recovery.conf.
primary_slot_name seems not so long name.It also has the advantage that we can add a couple more slot_* options
later. Will do that.
Ok. Here's a patch using slot_name everywhere user visible. There's a
couple of places in the code where 'slotname' is still used, but those
look more consistent that way in their context. I'll push that later
unless somebody suggests changes.
It's much easier to review changes after applying them when using
--word-diff=color --word-diff-regex='[^[:space:]\<\>\,]+'
as parameters to git diff/show.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachments:
0001-Consistently-spell-a-replication-slot-s-name-as-slot.patchtext/x-patch; charset=us-asciiDownload
>From 31bf302736625621c164366aaa578def09f57237 Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Thu, 5 Jun 2014 13:25:22 +0200
Subject: [PATCH] Consistently spell a replication slot's name as slot_name.
Previously there's been a mix between 'slotname' and 'slot_name'. It's
not nice to be inconsistent in a new feature. As a post beta1 initdb
is required now anyways, fix the inconsistencies.
Most the changes won't affect usage of replication slots because the
majority of changes is around function parameter names. The prominent
exception to that is that the recovery.conf parameter
'primary_slotname' is now named 'primary_slot_name'.
---
doc/src/sgml/func.sgml | 28 ++++++++++++-------------
doc/src/sgml/high-availability.sgml | 6 +++---
doc/src/sgml/logicaldecoding.sgml | 8 +++----
doc/src/sgml/protocol.sgml | 16 +++++++-------
doc/src/sgml/recovery-config.sgml | 6 +++---
src/backend/access/transam/recovery.conf.sample | 2 +-
src/backend/access/transam/xlog.c | 4 ++--
src/backend/catalog/system_views.sql | 8 +++----
src/bin/pg_basebackup/pg_recvlogical.c | 6 +++---
src/include/catalog/catversion.h | 2 +-
src/include/catalog/pg_proc.h | 12 +++++------
11 files changed, 49 insertions(+), 49 deletions(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index c4bcefd..5c906f3 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -16609,14 +16609,14 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
<indexterm>
<primary>pg_create_physical_replication_slot</primary>
</indexterm>
- <literal><function>pg_create_physical_replication_slot(<parameter>slotname</parameter> <type>name</type>)</function></literal>
+ <literal><function>pg_create_physical_replication_slot(<parameter>slot_name</parameter> <type>name</type>)</function></literal>
</entry>
<entry>
- (<parameter>slotname</parameter> <type>name</type>, <parameter>xlog_position</parameter> <type>pg_lsn</type>)
+ (<parameter>slot_name</parameter> <type>name</type>, <parameter>xlog_position</parameter> <type>pg_lsn</type>)
</entry>
<entry>
Creates a new physical replication slot named
- <parameter>slotname</parameter>. Streaming changes from a physical slot
+ <parameter>slot_name</parameter>. Streaming changes from a physical slot
is only possible with the walsender protocol - see <xref
linkend="protocol-replication">. Corresponds to the walsender protocol
command <literal>CREATE_REPLICATION_SLOT ... PHYSICAL</literal>.
@@ -16627,14 +16627,14 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
<indexterm>
<primary>pg_drop_replication_slot</primary>
</indexterm>
- <literal><function>pg_drop_replication_slot(<parameter>slotname</parameter> <type>name</type>)</function></literal>
+ <literal><function>pg_drop_replication_slot(<parameter>slot_name</parameter> <type>name</type>)</function></literal>
</entry>
<entry>
<type>void</type>
</entry>
<entry>
Drops the physical or logical replication slot
- named <parameter>slotname</parameter>. Same as walsender protocol
+ named <parameter>slot_name</parameter>. Same as walsender protocol
command <literal>DROP_REPLICATION_SLOT</>.
</entry>
</row>
@@ -16644,14 +16644,14 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
<indexterm>
<primary>pg_create_logical_replication_slot</primary>
</indexterm>
- <literal><function>pg_create_logical_replication_slot(<parameter>slotname</parameter> <type>name</type>, <parameter>plugin</parameter> <type>name</type>)</function></literal>
+ <literal><function>pg_create_logical_replication_slot(<parameter>slot_name</parameter> <type>name</type>, <parameter>plugin</parameter> <type>name</type>)</function></literal>
</entry>
<entry>
- (<parameter>slotname</parameter> <type>name</type>, <parameter>xlog_position</parameter> <type>pg_lsn</type>)
+ (<parameter>slot_name</parameter> <type>name</type>, <parameter>xlog_position</parameter> <type>pg_lsn</type>)
</entry>
<entry>
Creates a new logical (decoding) replication slot named
- <parameter>slotname</parameter> using the output plugin
+ <parameter>slot_name</parameter> using the output plugin
<parameter>plugin</parameter>. A call to this function has the same
effect as the replication protocol command
<literal>CREATE REPLICATION SLOT ... LOGICAL</literal>.
@@ -16663,16 +16663,16 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
<indexterm>
<primary>pg_logical_slot_get_changes</primary>
</indexterm>
- <literal><function>pg_logical_slot_get_changes(<parameter>slotname</parameter> <type>name</type>, <parameter>upto_lsn</parameter> <type>pg_lsn</type>, <parameter>upto_nchanges</parameter> <type>int</type>, VARIADIC <parameter>options</parameter> <type>text[]</type>)</function></literal>
+ <literal><function>pg_logical_slot_get_changes(<parameter>slot_name</parameter> <type>name</type>, <parameter>upto_lsn</parameter> <type>pg_lsn</type>, <parameter>upto_nchanges</parameter> <type>int</type>, VARIADIC <parameter>options</parameter> <type>text[]</type>)</function></literal>
</entry>
<entry>
(<parameter>location</parameter> <type>pg_lsn</type>, <parameter>xid</parameter> <type>xid</type>, <parameter>data</parameter> <type>text</type>)
</entry>
<entry>
- Returns changes in the slot <parameter>slotname</parameter>, starting
+ Returns changes in the slot <parameter>slot_name</parameter>, starting
from the point at which since changes have been consumed last. If
<parameter>upto_lsn</> and <parameter>upto_nchanges</> are NULL,
- logical decoding will continue until end of WAL. If
+ logical decoding will continue until end of WAL. If
<parameter>upto_lsn</> is non-NULL, decoding will include only
those transactions which commit prior to the specified LSN. If
<parameter>upto_nchanges</parameter> is non-NULL, decoding will
@@ -16688,7 +16688,7 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
<indexterm>
<primary>pg_logical_slot_peek_changes</primary>
</indexterm>
- <literal><function>pg_logical_slot_peek_changes(<parameter>slotname</parameter> <type>name</type>, <parameter>upto_lsn</parameter> <type>pg_lsn</type>, <parameter>upto_nchanges</parameter> <type>int</type>, VARIADIC <parameter>options</parameter> <type>text[]</type>)</function></literal>
+ <literal><function>pg_logical_slot_peek_changes(<parameter>slot_name</parameter> <type>name</type>, <parameter>upto_lsn</parameter> <type>pg_lsn</type>, <parameter>upto_nchanges</parameter> <type>int</type>, VARIADIC <parameter>options</parameter> <type>text[]</type>)</function></literal>
</entry>
<entry>
(<parameter>location</parameter> <type>text</type>, <parameter>xid</parameter> <type>xid</type>, <parameter>data</parameter> <type>text</type>)
@@ -16706,7 +16706,7 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
<indexterm>
<primary>pg_logical_slot_get_binary_changes</primary>
</indexterm>
- <literal><function>pg_logical_slot_get_binary_changes(<parameter>slotname</parameter> <type>name</type>, <parameter>upto_lsn</parameter> <type>pg_lsn</type>, <parameter>upto_nchanges</parameter> <type>int</type>, VARIADIC <parameter>options</parameter> <type>text[]</type>)</function></literal>
+ <literal><function>pg_logical_slot_get_binary_changes(<parameter>slot_name</parameter> <type>name</type>, <parameter>upto_lsn</parameter> <type>pg_lsn</type>, <parameter>upto_nchanges</parameter> <type>int</type>, VARIADIC <parameter>options</parameter> <type>text[]</type>)</function></literal>
</entry>
<entry>
(<parameter>location</parameter> <type>pg_lsn</type>, <parameter>xid</parameter> <type>xid</type>, <parameter>data</parameter> <type>bytea</type>)
@@ -16723,7 +16723,7 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
<indexterm>
<primary>pg_logical_slot_peek_binary_changes</primary>
</indexterm>
- <literal><function>pg_logical_slot_peek_binary_changes(<parameter>slotname</parameter> <type>name</type>, <parameter>upto_lsn</parameter> <type>pg_lsn</type>, <parameter>upto_nchanges</parameter> <type>int</type>, VARIADIC <parameter>options</parameter> <type>text[]</type>)</function></literal>
+ <literal><function>pg_logical_slot_peek_binary_changes(<parameter>slot_name</parameter> <type>name</type>, <parameter>upto_lsn</parameter> <type>pg_lsn</type>, <parameter>upto_nchanges</parameter> <type>int</type>, VARIADIC <parameter>options</parameter> <type>text[]</type>)</function></literal>
</entry>
<entry>
(<parameter>location</parameter> <type>pg_lsn</type>, <parameter>xid</parameter> <type>xid</type>, <parameter>data</parameter> <type>bytea</type>)
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 7bba651..657097d 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -929,7 +929,7 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
You can create a replication slot like this:
<programlisting>
postgres=# SELECT * FROM pg_create_physical_replication_slot('node_a_slot');
- slotname | xlog_position
+ slot_name | xlog_position
-------------+---------------
node_a_slot |
@@ -939,13 +939,13 @@ postgres=# SELECT * FROM pg_replication_slots;
node_a_slot | physical | | | f | |
(1 row)
</programlisting>
- To configure the standby to use this slot, <varname>primary_slotname</>
+ To configure the standby to use this slot, <varname>primary_slot_name</>
should be configured in the standby's <filename>recovery.conf</>.
Here is a simple example:
<programlisting>
standby_mode = 'on'
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
-primary_slotname = 'node_a_slot'
+primary_slot_name = 'node_a_slot'
</programlisting>
</para>
</sect3>
diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index 549f2bc..a2108d6 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -54,7 +54,7 @@
<programlisting>
postgres=# -- Create a slot named 'regression_slot' using the output plugin 'test_decoding'
postgres=# SELECT * FROM pg_create_logical_replication_slot('regression_slot', 'test_decoding');
- slotname | xlog_position
+ slot_name | xlog_position
-----------------+---------------
regression_slot | 0/16B1970
(1 row)
@@ -256,9 +256,9 @@ CTRL-C
<sect1 id="logicaldecoding-walsender">
<title>Streaming Replication Protocol Interface</title>
<para>
- The <literal>CREATE_REPLICATION_SLOT slotname LOGICAL
- options</literal>, <literal>DROP_REPLICATION_SLOT slotname</literal>
- and <literal>START_REPLICATION SLOT slotname LOGICAL options</literal>
+ The <literal>CREATE_REPLICATION_SLOT slot_name LOGICAL
+ options</literal>, <literal>DROP_REPLICATION_SLOT slot_name</literal>
+ and <literal>START_REPLICATION SLOT slot_name LOGICAL options</literal>
commands can be used to create, drop and stream changes from a replication
slot respectively. These commands are only available over a replication
connection; they cannot be used via SQL.
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index ee3d9de..c6eb863 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -1428,7 +1428,7 @@ The commands accepted in walsender mode are:
</varlistentry>
<varlistentry>
- <term>CREATE_REPLICATION_SLOT <replaceable class="parameter">slotname</> { <literal>PHYSICAL</> | <literal>LOGICAL</> <replaceable class="parameter">output_plugin</> } <indexterm><primary>CREATE_REPLICATION_SLOT</primary></indexterm></term>
+ <term>CREATE_REPLICATION_SLOT <replaceable class="parameter">slot_name</> { <literal>PHYSICAL</> | <literal>LOGICAL</> <replaceable class="parameter">output_plugin</> } <indexterm><primary>CREATE_REPLICATION_SLOT</primary></indexterm></term>
<listitem>
<para>
Create a physical or logical replication
@@ -1437,7 +1437,7 @@ The commands accepted in walsender mode are:
</para>
<variablelist>
<varlistentry>
- <term><replaceable class="parameter">slotname</></term>
+ <term><replaceable class="parameter">slot_name</></term>
<listitem>
<para>
The name of the slot to create. Must be a valid replication slot
@@ -1460,7 +1460,7 @@ The commands accepted in walsender mode are:
</varlistentry>
<varlistentry>
- <term>START_REPLICATION [<literal>SLOT</literal> <replaceable class="parameter">slotname</>] [<literal>PHYSICAL</literal>] <replaceable class="parameter">XXX/XXX</> [<literal>TIMELINE</literal> <replaceable class="parameter">tli</>]</term>
+ <term>START_REPLICATION [<literal>SLOT</literal> <replaceable class="parameter">slot_name</>] [<literal>PHYSICAL</literal>] <replaceable class="parameter">XXX/XXX</> [<literal>TIMELINE</literal> <replaceable class="parameter">tli</>]</term>
<listitem>
<para>
Instructs server to start streaming WAL, starting at
@@ -1506,7 +1506,7 @@ The commands accepted in walsender mode are:
<para>
If a slot's name is provided
- via <replaceable class="parameter">slotname</>, it will be updated
+ via <replaceable class="parameter">slot_name</>, it will be updated
as replication progresses so that the server knows which WAL segments -
and if <varname>hot_standby_feedback</> is on which transactions -
are still needed by the standby.
@@ -1788,7 +1788,7 @@ The commands accepted in walsender mode are:
</listitem>
</varlistentry>
<varlistentry>
- <term>START_REPLICATION <literal>SLOT</literal> <replaceable class="parameter">slotname</> <literal>LOGICAL</literal> <replaceable class="parameter">XXX/XXX</> [ ( <replaceable>option_name</replaceable> [<replaceable>option_value</replaceable>] [, ... ] ) ]</term>
+ <term>START_REPLICATION <literal>SLOT</literal> <replaceable class="parameter">slot_name</> <literal>LOGICAL</literal> <replaceable class="parameter">XXX/XXX</> [ ( <replaceable>option_name</replaceable> [<replaceable>option_value</replaceable>] [, ... ] ) ]</term>
<listitem>
<para>
Instructs server to start streaming WAL for logical replication, starting
@@ -1810,7 +1810,7 @@ The commands accepted in walsender mode are:
<variablelist>
<varlistentry>
- <term><literal>SLOT</literal> <replaceable class="parameter">slotname</></term>
+ <term><literal>SLOT</literal> <replaceable class="parameter">slot_name</></term>
<listitem>
<para>
The name of the slot to stream changes from. This parameter is required,
@@ -1850,7 +1850,7 @@ The commands accepted in walsender mode are:
</varlistentry>
<varlistentry>
- <term>DROP_REPLICATION_SLOT <replaceable class="parameter">slotname</></term>
+ <term>DROP_REPLICATION_SLOT <replaceable class="parameter">slot_name</></term>
<listitem>
<para>
Drops a replication slot, freeing any reserved server-side resources. If
@@ -1858,7 +1858,7 @@ The commands accepted in walsender mode are:
</para>
<variablelist>
<varlistentry>
- <term><replaceable class="parameter">slotname</></term>
+ <term><replaceable class="parameter">slot_name</></term>
<listitem>
<para>
The name of the slot to drop.
diff --git a/doc/src/sgml/recovery-config.sgml b/doc/src/sgml/recovery-config.sgml
index 762207e..76f9d03 100644
--- a/doc/src/sgml/recovery-config.sgml
+++ b/doc/src/sgml/recovery-config.sgml
@@ -370,10 +370,10 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
</para>
</listitem>
</varlistentry>
- <varlistentry id="primary-slotname" xreflabel="primary_slotname">
- <term><varname>primary_slotname</varname> (<type>string</type>)
+ <varlistentry id="primary-slot-name" xreflabel="primary_slot_name">
+ <term><varname>primary_slot_name</varname> (<type>string</type>)
<indexterm>
- <primary><varname>primary_slotname</> recovery parameter</primary>
+ <primary><varname>primary_slot_name</> recovery parameter</primary>
</indexterm>
</term>
<listitem>
diff --git a/src/backend/access/transam/recovery.conf.sample b/src/backend/access/transam/recovery.conf.sample
index 745f270..7657df3 100644
--- a/src/backend/access/transam/recovery.conf.sample
+++ b/src/backend/access/transam/recovery.conf.sample
@@ -125,7 +125,7 @@
# removal on the upstream node. This setting has no effect if primary_conninfo
# is not set.
#
-#primary_slotname = ''
+#primary_slot_name = ''
#
# By default, a standby server keeps restoring XLOG records from the
# primary indefinitely. If you want to stop the standby mode, finish recovery
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index d675560..926bb89 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -5221,12 +5221,12 @@ readRecoveryCommandFile(void)
(errmsg_internal("primary_conninfo = '%s'",
PrimaryConnInfo)));
}
- else if (strcmp(item->name, "primary_slotname") == 0)
+ else if (strcmp(item->name, "primary_slot_name") == 0)
{
ReplicationSlotValidateName(item->value, ERROR);
PrimarySlotName = pstrdup(item->value);
ereport(DEBUG2,
- (errmsg_internal("primary_slotname = '%s'",
+ (errmsg_internal("primary_slot_name = '%s'",
PrimarySlotName)));
}
else if (strcmp(item->name, "trigger_file") == 0)
diff --git a/src/backend/catalog/system_views.sql b/src/backend/catalog/system_views.sql
index 42a4c00..793a92b 100644
--- a/src/backend/catalog/system_views.sql
+++ b/src/backend/catalog/system_views.sql
@@ -850,7 +850,7 @@ CREATE OR REPLACE FUNCTION
RETURNS SETOF record LANGUAGE internal STABLE ROWS 100 AS 'jsonb_to_recordset';
CREATE OR REPLACE FUNCTION pg_logical_slot_get_changes(
- IN slotname name, IN upto_lsn pg_lsn, IN upto_nchanges int, VARIADIC options text[] DEFAULT '{}',
+ IN slot_name name, IN upto_lsn pg_lsn, IN upto_nchanges int, VARIADIC options text[] DEFAULT '{}',
OUT location pg_lsn, OUT xid xid, OUT data text)
RETURNS SETOF RECORD
LANGUAGE INTERNAL
@@ -858,7 +858,7 @@ VOLATILE ROWS 1000 COST 1000
AS 'pg_logical_slot_get_changes';
CREATE OR REPLACE FUNCTION pg_logical_slot_peek_changes(
- IN slotname name, IN upto_lsn pg_lsn, IN upto_nchanges int, VARIADIC options text[] DEFAULT '{}',
+ IN slot_name name, IN upto_lsn pg_lsn, IN upto_nchanges int, VARIADIC options text[] DEFAULT '{}',
OUT location pg_lsn, OUT xid xid, OUT data text)
RETURNS SETOF RECORD
LANGUAGE INTERNAL
@@ -866,7 +866,7 @@ VOLATILE ROWS 1000 COST 1000
AS 'pg_logical_slot_peek_changes';
CREATE OR REPLACE FUNCTION pg_logical_slot_get_binary_changes(
- IN slotname name, IN upto_lsn pg_lsn, IN upto_nchanges int, VARIADIC options text[] DEFAULT '{}',
+ IN slot_name name, IN upto_lsn pg_lsn, IN upto_nchanges int, VARIADIC options text[] DEFAULT '{}',
OUT location pg_lsn, OUT xid xid, OUT data bytea)
RETURNS SETOF RECORD
LANGUAGE INTERNAL
@@ -874,7 +874,7 @@ VOLATILE ROWS 1000 COST 1000
AS 'pg_logical_slot_get_binary_changes';
CREATE OR REPLACE FUNCTION pg_logical_slot_peek_binary_changes(
- IN slotname name, IN upto_lsn pg_lsn, IN upto_nchanges int, VARIADIC options text[] DEFAULT '{}',
+ IN slot_name name, IN upto_lsn pg_lsn, IN upto_nchanges int, VARIADIC options text[] DEFAULT '{}',
OUT location pg_lsn, OUT xid xid, OUT data bytea)
RETURNS SETOF RECORD
LANGUAGE INTERNAL
diff --git a/src/bin/pg_basebackup/pg_recvlogical.c b/src/bin/pg_basebackup/pg_recvlogical.c
index cbbba9e..5823731 100644
--- a/src/bin/pg_basebackup/pg_recvlogical.c
+++ b/src/bin/pg_basebackup/pg_recvlogical.c
@@ -89,10 +89,10 @@ usage(void)
printf(_(" -P, --plugin=PLUGIN use output plugin PLUGIN (default: %s)\n"), plugin);
printf(_(" -s, --status-interval=SECS\n"
" time between status packets sent to server (default: %d)\n"), (standby_message_timeout / 1000));
- printf(_(" -S, --slot=SLOT use existing replication slot SLOT instead of starting a new one\n"));
+ printf(_(" -S, --slot=SLOT name of the logical replication slot\n"));
printf(_("\nAction to be performed:\n"));
- printf(_(" --create create a new replication slot (for the slotname see --slot)\n"));
- printf(_(" --start start streaming in a replication slot (for the slotname see --slot)\n"));
+ printf(_(" --create create a new replication slot (for the slot's name see --slot)\n"));
+ printf(_(" --start start streaming in a replication slot (for the slot's name see --slot)\n"));
printf(_(" --drop drop the replication slot (for the slotname see --slot)\n"));
printf(_("\nReport bugs to <pgsql-bugs@postgresql.org>.\n"));
}
diff --git a/src/include/catalog/catversion.h b/src/include/catalog/catversion.h
index c46a92b..93afbbe 100644
--- a/src/include/catalog/catversion.h
+++ b/src/include/catalog/catversion.h
@@ -53,6 +53,6 @@
*/
/* yyyymmddN */
-#define CATALOG_VERSION_NO 201405111
+#define CATALOG_VERSION_NO 201406051
#endif
diff --git a/src/include/catalog/pg_proc.h b/src/include/catalog/pg_proc.h
index 72170af..c5bdccf 100644
--- a/src/include/catalog/pg_proc.h
+++ b/src/include/catalog/pg_proc.h
@@ -4956,21 +4956,21 @@ DATA(insert OID = 3473 ( spg_range_quad_leaf_consistent PGNSP PGUID 12 1 0 0 0
DESCR("SP-GiST support for quad tree over range");
/* replication slots */
-DATA(insert OID = 3779 ( pg_create_physical_replication_slot PGNSP PGUID 12 1 0 0 0 f f f f f f v 1 0 2249 "19" "{19,19,3220}" "{i,o,o}" "{slotname,slotname,xlog_position}" _null_ pg_create_physical_replication_slot _null_ _null_ _null_ ));
+DATA(insert OID = 3779 ( pg_create_physical_replication_slot PGNSP PGUID 12 1 0 0 0 f f f f f f v 1 0 2249 "19" "{19,19,3220}" "{i,o,o}" "{slot_name,slot_name,xlog_position}" _null_ pg_create_physical_replication_slot _null_ _null_ _null_ ));
DESCR("create a physical replication slot");
DATA(insert OID = 3780 ( pg_drop_replication_slot PGNSP PGUID 12 1 0 0 0 f f f f f f v 1 0 2278 "19" _null_ _null_ _null_ _null_ pg_drop_replication_slot _null_ _null_ _null_ ));
DESCR("drop a replication slot");
DATA(insert OID = 3781 ( pg_get_replication_slots PGNSP PGUID 12 1 10 0 0 f f f f f t s 0 0 2249 "" "{19,19,25,26,16,28,28,3220}" "{o,o,o,o,o,o,o,o}" "{slot_name,plugin,slot_type,datoid,active,xmin,catalog_xmin,restart_lsn}" _null_ pg_get_replication_slots _null_ _null_ _null_ ));
DESCR("information about replication slots currently in use");
-DATA(insert OID = 3786 ( pg_create_logical_replication_slot PGNSP PGUID 12 1 0 0 0 f f f f f f v 2 0 2249 "19 19" "{19,19,25,3220}" "{i,i,o,o}" "{slotname,plugin,slotname,xlog_position}" _null_ pg_create_logical_replication_slot _null_ _null_ _null_ ));
+DATA(insert OID = 3786 ( pg_create_logical_replication_slot PGNSP PGUID 12 1 0 0 0 f f f f f f v 2 0 2249 "19 19" "{19,19,25,3220}" "{i,i,o,o}" "{slot_name,plugin,slot_name,xlog_position}" _null_ pg_create_logical_replication_slot _null_ _null_ _null_ ));
DESCR("set up a logical replication slot");
-DATA(insert OID = 3782 ( pg_logical_slot_get_changes PGNSP PGUID 12 1000 1000 25 0 f f f f f t v 4 0 2249 "19 3220 23 1009" "{19,3220,23,1009,3220,28,25}" "{i,i,i,v,o,o,o}" "{slotname,upto_lsn,upto_nchanges,options,location,xid,data}" _null_ pg_logical_slot_get_changes _null_ _null_ _null_ ));
+DATA(insert OID = 3782 ( pg_logical_slot_get_changes PGNSP PGUID 12 1000 1000 25 0 f f f f f t v 4 0 2249 "19 3220 23 1009" "{19,3220,23,1009,3220,28,25}" "{i,i,i,v,o,o,o}" "{slot_name,upto_lsn,upto_nchanges,options,location,xid,data}" _null_ pg_logical_slot_get_changes _null_ _null_ _null_ ));
DESCR("get changes from replication slot");
-DATA(insert OID = 3783 ( pg_logical_slot_get_binary_changes PGNSP PGUID 12 1000 1000 25 0 f f f f f t v 4 0 2249 "19 3220 23 1009" "{19,3220,23,1009,3220,28,17}" "{i,i,i,v,o,o,o}" "{slotname,upto_lsn,upto_nchanges,options,location,xid,data}" _null_ pg_logical_slot_get_binary_changes _null_ _null_ _null_ ));
+DATA(insert OID = 3783 ( pg_logical_slot_get_binary_changes PGNSP PGUID 12 1000 1000 25 0 f f f f f t v 4 0 2249 "19 3220 23 1009" "{19,3220,23,1009,3220,28,17}" "{i,i,i,v,o,o,o}" "{slot_name,upto_lsn,upto_nchanges,options,location,xid,data}" _null_ pg_logical_slot_get_binary_changes _null_ _null_ _null_ ));
DESCR("get binary changes from replication slot");
-DATA(insert OID = 3784 ( pg_logical_slot_peek_changes PGNSP PGUID 12 1000 1000 25 0 f f f f f t v 4 0 2249 "19 3220 23 1009" "{19,3220,23,1009,3220,28,25}" "{i,i,i,v,o,o,o}" "{slotname,upto_lsn,upto_nchanges,options,location,xid,data}" _null_ pg_logical_slot_peek_changes _null_ _null_ _null_ ));
+DATA(insert OID = 3784 ( pg_logical_slot_peek_changes PGNSP PGUID 12 1000 1000 25 0 f f f f f t v 4 0 2249 "19 3220 23 1009" "{19,3220,23,1009,3220,28,25}" "{i,i,i,v,o,o,o}" "{slot_name,upto_lsn,upto_nchanges,options,location,xid,data}" _null_ pg_logical_slot_peek_changes _null_ _null_ _null_ ));
DESCR("peek at changes from replication slot");
-DATA(insert OID = 3785 ( pg_logical_slot_peek_binary_changes PGNSP PGUID 12 1000 1000 25 0 f f f f f t v 4 0 2249 "19 3220 23 1009" "{19,3220,23,1009,3220,28,17}" "{i,i,i,v,o,o,o}" "{slotname,upto_lsn,upto_nchanges,options,location,xid,data}" _null_ pg_logical_slot_peek_binary_changes _null_ _null_ _null_ ));
+DATA(insert OID = 3785 ( pg_logical_slot_peek_binary_changes PGNSP PGUID 12 1000 1000 25 0 f f f f f t v 4 0 2249 "19 3220 23 1009" "{19,3220,23,1009,3220,28,17}" "{i,i,i,v,o,o,o}" "{slot_name,upto_lsn,upto_nchanges,options,location,xid,data}" _null_ pg_logical_slot_peek_binary_changes _null_ _null_ _null_ ));
DESCR("peek at binary changes from replication slot");
/* event triggers */
--
2.0.0.rc2.4.g1dc51c6.dirty
On Thu, Jun 5, 2014 at 7:12 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
BTW, what about also renaming pg_llog directory? I'm afraid that
a user can confuse pg_log with pg_llog.We have:
* pg_ldecoding (Heikki)
* pg_lcse or pg_lcset (Petr)
* pg_logical (Andres)I like, what a surprise, my own suggestion best. The name seems more
versatile because it's not restricted to decoding.The problem with pg_logical is that it's not restricted to much at all ;-),
"logical" is an awfully generic name.
True. But we don't have anything else with which it's liable to be confused.
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.
--
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
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Robert Haas wrote:
For my part, I'd strongly prefer a name based on the term "logical
decoding".
There is no reason not to use long names, so I think pg_logical_decoding
is fine.
+1
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On June 5, 2014 7:43:06 PM CEST, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Robert Haas wrote:
For my part, I'd strongly prefer a name based on the term "logical
decoding".There is no reason not to use long names, so I think
pg_logical_decoding
is fine.
+1
Still not a fan oft having decoding in the name. I've at least one patch pending (replication identifiers, submitted a couple months back) that will need to stash a couple of files somewhere. And it's for the apply side, not the decoding side.
Andres
--
Please excuse brevity and formatting - I am writing this on my mobile phone.
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
On 05/06/14 19:56, Andres Freund wrote:
On June 5, 2014 7:43:06 PM CEST, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Robert Haas wrote:
For my part, I'd strongly prefer a name based on the term "logical
decoding".There is no reason not to use long names, so I think
pg_logical_decoding
is fine.
+1
Still not a fan oft having decoding in the name. I've at least one patch pending (replication identifiers, submitted a couple months back) that will need to stash a couple of files somewhere. And it's for the apply side, not the decoding side.
Personally I like your suggestion of pg_logical
--
Petr Jelinek 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
On Fri, Jun 6, 2014 at 2:43 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Robert Haas wrote:
For my part, I'd strongly prefer a name based on the term "logical
decoding".There is no reason not to use long names, so I think pg_logical_decoding
is fine.+1
Indeed. With such a name there is no way to misunderstand its content.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2014-06-05 12:57:57 +0200, Andres Freund wrote:
BTW, what about also renaming pg_llog directory? I'm afraid that
a user can confuse pg_log with pg_llog.We have:
* pg_ldecoding (Heikki)
* pg_lcse or pg_lcset (Petr)
* pg_logical (Andres)I like, what a surprise, my own suggestion best. The name seems more
versatile because it's not restricted to decoding.
So, we haven't really come to any conclusion in this thread and we
better change it soon, if at all. So, unless somebody protests against
it I'm going to rename pg_llog to pg_logical and document it.
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