list of flags that pg_settings_get_flags reports
Hi,
In the docs, the display of the list of flags that pg_settings_get_flags reports looks a bit odd
to me [*1]. To make it smarter, how about using instead of
, to list thoes flags within ? Patch attached.
Regards,
[*1]
https://www.postgresql.org/docs/devel/functions-info.html#id-1.5.8.32.19.2.2.25.1.1.1
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATIONFrom 735f4f095516ac7b1d4d838aeada3acffb4ae036 Mon Sep 17 00:00:00 2001
From: Fujii Masao
Date: Fri, 15 Jul 2022 22:19:58 +0900
Subject: [PATCH] Improve pg_settings_get_flags docs.
---
doc/src/sgml/func.sgml | 52 +-
1 file changed, 31 insertions(+), 21 deletions(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index b6783b7ad0..f79a8e807c 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -24976,27 +24976,37 @@ SELECT currval(pg_get_serial_sequence('sometable',
'id'));
NULL if it does not exist. The result is
an empty array if the GUC exists but there are no flags to show.
Only the most useful flags are exposed, as of the following:
-
-
- EXPLAIN: parameters included in
- EXPLAIN (SETTINGS) commands.
-
-
- NO_SHOW_ALL: parameters excluded from
- SHOW ALL commands.
-
-
- NO_RESET_ALL: parameters excluded from
- RESET ALL commands.
-
-
- NOT_IN_SAMPLE: parameters not included in
- postgresql.conf by default.
-
-
- RUNTIME_COMPUTED: runtime-computed parameters.
-
-
+
+
+
+ EXPLAIN: parameters included in
+ EXPLAIN (SETTINGS) commands.
+
+
+
+
+ NO_SHOW_ALL: parameters excluded from
+ SHOW ALL commands.
+
+
+
+
+ NO_RESET_ALL: parameters excluded from
+ RESET ALL commands.
+
+
+
+
+ NOT_IN_SAMPLE: parameters not included in
+ postgresql.conf by default.
+
+
+
+
+ RUNTIME_COMPUTED: runtime-computed parameters.
+
+
+
--
2.36.0
Re: list of flags that pg_settings_get_flags reports
On 2022-Jul-15, Fujii Masao wrote: > Hi, > > In the docs, the display of the list of flags that > pg_settings_get_flags reports looks a bit odd to me [*1]. To make it > smarter, how about using instead of , to > list thoes flags within ? Patch attached. I think it should be a separate table, like tables 9.75-9.77 lists properties for various functions. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "The problem with the facetime model is not just that it's demoralizing, but that the people pretending to work interrupt the ones actually working." (Paul Graham)
Re: Fwd: Adding more detail to pg_upgrade documentation
Thank you Bruce ! On Fri, 15 Jul 2022 at 2:04 AM, Bruce Momjian wrote: > On Sat, Jul 9, 2022 at 10:38:30PM -0400, Bruce Momjian wrote: > > > (source: https://www.postgresql.org/docs/devel/pgupgrade.html) > > > > > > I'm a new contributor so please forgive me if I'm on the wrong > track, > > > but if you follow this step, won't you also be ensuring that > replication > > > slots do not need to be migrated, since you've just ensured that > standby > > > clusters are in sync with the primary cluster? Please let me know > if I'm > > > missing anything! > > > > I have written the attached patch to document this. > > Patch applied to all supported versions. > > -- > Bruce Momjian https://momjian.us > EDB https://enterprisedb.com > > Indecision is a decision. Inaction is an action. Mark Batterson > >
Re: pg_advisory_unlock(null)
On Thu, Jul 14, 2022 at 6:36 AM PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/12/functions-admin.html > Description: > > Hello! > There is no information in documentation about pg_advisory_unlock with NULL > value. > This call: select pg_advisory_unlock(null), returns null without reporting, > but according to the documentation it was expected either false or true. > Maybe add information about null value? > version: 12.10 > It is defined as strict because there is nothing meaningful that could be done with a null input. Saying that seems unnecessary; I'm sure if you look you will find many more places where this complaint applies. If I did anything it would be to add a comment to the Function and Operators page that says something like: Many of the functions listed herein cannot produce a meaningful result when supplied with null arguments. These functions will simply produce a null output without being invoked. These are not explicitly labelled in the documentation, though you may inspect the system catalog to confirm whether a given function is or is not defined as being "strict" (returns null on null input). In most cases one should assume that unless the behavior regarding null inputs is explained that the function in question is defined to be strict. Operators likewise tend to produce null outputs if at least one of their inputs are null. Aggregate and window functions are the most common exception to this rule. David J.
Re: list of flags that pg_settings_get_flags reports
On Fri, Jul 15, 2022 at 03:40:08PM +0200, Alvaro Herrera wrote: > I think it should be a separate table, like tables 9.75-9.77 lists > properties for various functions. Err, sorry for missing that. I did not notice that a list would be treated as separate lines in the existing function table. Adding a table at the bottom of the function list sounds fine to me. I can handle it if you want, as that's something I have committed originally. -- Michael signature.asc Description: PGP signature
