slotname vs slot_name

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

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