docs: pg_replication_origin_oid() description does not match behaviour
Hi
From the documentation for pg_replication_origin_oid() [1]https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-REPLICATION-TABLE:
Looks up a replication origin by name and returns the internal ID.
If no such replication origin is found an error is thrown.
However, it actually returns NULL if the origin does not exist:
postgres=# SELECT * FROM pg_replication_origin;
roident | roname
---------+--------
(0 rows)
postgres=# SELECT pg_replication_origin_oid('foo'),
pg_replication_origin_oid('foo') IS NULL;
pg_replication_origin_oid | ?column?
---------------------------+----------
| t
(1 row)
Given that the code has remained unchanged since the function was
introduced in 9.5, it seems reasonable to change the documentation
to match the function behaviour rather than the other way round.
Regards
Ian Barwick
[1]: https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-REPLICATION-TABLE
--
EnterpriseDB: https://www.enterprisedb.com
Attachments:
doc-pg_replication_origin_oid.patchtext/x-patch; charset=US-ASCII; name=doc-pg_replication_origin_oid.patchDownload
commit 9e0d549002d97b20261554c5f45ad5149916994a
Author: Ian Barwick <ian.barwick@enterprisedb.com>
Date: Tue Jan 18 09:52:16 2022 +0900
doc: fix pg_replication_origin_oid() description
If the specified replication origin does not exist, NULL is returned;
an error is not thrown.
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index a270f89dfe..027dfa4b82 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -26524,7 +26524,7 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
</para>
<para>
Looks up a replication origin by name and returns the internal ID. If
- no such replication origin is found an error is thrown.
+ no such replication origin is found, <literal>NULL</literal> is returned.
</para></entry>
</row>
On Tue, Jan 18, 2022 at 10:19:41AM +0900, Ian Lawrence Barwick wrote:
Given that the code has remained unchanged since the function was
introduced in 9.5, it seems reasonable to change the documentation
to match the function behaviour rather than the other way round.
Obviously. I'll go fix that as you suggest, if there are no
objections.
--
Michael
On 1/17/22, 5:24 PM, "Michael Paquier" <michael@paquier.xyz> wrote:
On Tue, Jan 18, 2022 at 10:19:41AM +0900, Ian Lawrence Barwick wrote:
Given that the code has remained unchanged since the function was
introduced in 9.5, it seems reasonable to change the documentation
to match the function behaviour rather than the other way round.Obviously. I'll go fix that as you suggest, if there are no
objections.
+1
Nathan
On Tue, Jan 18, 2022 at 06:20:22PM +0000, Bossart, Nathan wrote:
+1
And done.
--
Michael
2022年1月19日(水) 10:40 Michael Paquier <michael@paquier.xyz>:
On Tue, Jan 18, 2022 at 06:20:22PM +0000, Bossart, Nathan wrote:
+1
And done.
Thanks!
Ian Barwick
--
EnterpriseDB: https://www.enterprisedb.com