Subject: pg_create_logical_replication_slot returns text instead of name

From: Masahiko Sawada <[email-masked]>
Date: Thu, 12 Jul 2018 19:00:48 +0900

Hi,

The documentation[1] says that both pg_create_logical_replication_slot
and pg_create_physical_replication_slot returns slot_name as a name
type. But only pg_create_logical_replication_slot returns it as text
type. I think these should be united as the name type. Attached small
patch fixes it.

[1] https://www.postgresql.org/docs/devel/static/functions-admin.html#FUNCTIONS-REPLICATION

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

---

From: Michael Paquier <[email-masked]>
Date: Thu, 12 Jul 2018 22:18:53 +0900

> [1] https://www.postgresql.org/docs/devel/static/functions-admin.html#FUNCTIONS-REPLICATION

That's a small thing, but I agree with you.  As far as I can see slot
names are always mapped with the name type.  I'll push that tomorrow if
there are no objections.
--
Michael

---

From: Michael Paquier <[email-masked]>
Date: Fri, 13 Jul 2018 09:48:58 +0900

> names are always mapped with the name type.  I'll push that tomorrow if

Pushed, with a catalog version bump.

While double-checking things, I have noticed that pg_stat_wal_receiver
also uses text for slot names.  I am not sure if this one is worth
bothering as the docs point out the correct type, just mentioning.
--
Michael

---

From: Masahiko Sawada <[email-masked]>
Date: Fri, 13 Jul 2018 11:14:01 +0900

> Pushed, with a catalog version bump.

Thank you!

> bothering as the docs point out the correct type, just mentioning.

Hmm, I'm also not sure about the policy of usage of name data type for
columns that show an object identifier on external servers. There is a
similar case; we have the pubname in pg_subscritpion as name type
whereas the subpublications in pg_subscription is text[] type.

Regards,

---

From: Michael Paquier <[email-masked]>
Date: Fri, 13 Jul 2018 11:22:11 +0900

> whereas the subpublications in pg_subscription is text[] type.

Let's not bother then.  In the case of the function you pointed out the
intention behind the code was clear anyway, so that's better now.
--
Michael

---

From: Masahiko Sawada <[email-masked]>
Date: Fri, 13 Jul 2018 11:28:01 +0900

> intention behind the code was clear anyway, so that's better now.

Yeah, I agreed with you.

Regards,