delta/postgresql.git/doc/src/sgml/ref, branch master git.postgresql.org: git/postgresql.git Revert "Add USER SET parameter values for pg_db_role_setting" 2023-05-17T17:28:57+00:00 Alexander Korotkov akorotkov@postgresql.org 2023-05-17T17:06:50+00:00 b9a7a822723aebb16cbe7e5fb874e5124745b07e This reverts commit 096dd80f3ccc and its fixups beecbe8e5001, afdd9f7f0e00, 529da086ba, db93e739ac61. Catversion is bumped. Discussion: https://postgr.es/m/d46f9265-ff3c-6743-2278-6772598233c2%40pgmasters.net 
This reverts commit 096dd80f3ccc and its fixups beecbe8e5001, afdd9f7f0e00,
529da086ba, db93e739ac61.

Catversion is bumped.

Discussion: https://postgr.es/m/d46f9265-ff3c-6743-2278-6772598233c2%40pgmasters.net
Tighten usage of PSQL_WATCH_PAGER. 2023-05-12T20:11:14+00:00 Tom Lane tgl@sss.pgh.pa.us 2023-05-12T20:11:14+00:00 51b2c08798867cb9788090704b37c4698b456240 Don't use PSQL_WATCH_PAGER when stdin/stdout are not a terminal. This corresponds to the restrictions on when other commands will use [PSQL_]PAGER. There isn't a lot of sense in trying to use a pager in non-interactive cases, and doing so allows an environment setting to break our tests. Also, ignore PSQL_WATCH_PAGER if it is set but empty or all-blank, for the same reasons we ignore such settings of [PSQL_]PAGER (see commit 18f8f784c). No documentation change is really needed, since there is nothing suggesting that these constraints on [PSQL_]PAGER didn't already apply to PSQL_WATCH_PAGER too. But I rearranged the text a little to make it read more naturally (IMHO anyway). Per report from Pavel Stehule. Back-patch to v15 where PSQL_WATCH_PAGER was introduced. Discussion: https://postgr.es/m/CAFj8pRDTwFzmEWdA-gdAcUh0ZnxUioSfTMre71WyB_wNJy-8gw@mail.gmail.com 
Don't use PSQL_WATCH_PAGER when stdin/stdout are not a terminal.
This corresponds to the restrictions on when other commands will
use [PSQL_]PAGER.  There isn't a lot of sense in trying to use a
pager in non-interactive cases, and doing so allows an environment
setting to break our tests.

Also, ignore PSQL_WATCH_PAGER if it is set but empty or all-blank,
for the same reasons we ignore such settings of [PSQL_]PAGER (see
commit 18f8f784c).

No documentation change is really needed, since there is nothing
suggesting that these constraints on [PSQL_]PAGER didn't already
apply to PSQL_WATCH_PAGER too.  But I rearranged the text
a little to make it read more naturally (IMHO anyway).

Per report from Pavel Stehule.  Back-patch to v15 where
PSQL_WATCH_PAGER was introduced.

Discussion: https://postgr.es/m/CAFj8pRDTwFzmEWdA-gdAcUh0ZnxUioSfTMre71WyB_wNJy-8gw@mail.gmail.com
doc: Fix typo in pg_amcheck for term "schema" 2023-05-02T02:40:46+00:00 Michael Paquier michael@paquier.xyz 2023-05-02T02:40:46+00:00 6fd8ae6888847da842ee4810fcd83b013cbed27f Author: Alexander Lakhin Discussion: https://postgr.es/m/e8c38840-596a-83d6-bd8d-cebc51111572@gmail.com Backpatch-through: 14 
Author: Alexander Lakhin
Discussion: https://postgr.es/m/e8c38840-596a-83d6-bd8d-cebc51111572@gmail.com
Backpatch-through: 14
Put new command-line option into sensible order in help output 2023-04-17T09:09:17+00:00 Peter Eisentraut peter@eisentraut.org 2023-04-17T09:09:17+00:00 2434d60a2ae977a460eda401fd9f99cf619f4743 We have two existing conventions for long options: either alphabetical among short options, or all long options after all the short options. But the convention apparently used here, next to a functionally related option, is not one of them. 
We have two existing conventions for long options: either alphabetical
among short options, or all long options after all the short options.
But the convention apparently used here, next to a functionally
related option, is not one of them.
Doc: remove notes about the version vacuumdb options are valid from 2023-04-16T21:28:34+00:00 David Rowley drowley@postgresql.org 2023-04-16T21:28:34+00:00 fde9c068818246f6d79649eff355a2b95106991d Here we remove the notes which mention which version the given vacuumdb option is available from. There are now 11 of these notes and they're both quite untidy and take up far more space than they seem to be worth. On running a print preview of the compiled HTML, removing these notes saves about 1 A4 page (~20% less space). If people need to see which options are available on older versions, then consulting the documents for that version seems like a good idea. In any case, when using newer vacuumdb versions on older servers, the user will receive an error if they try to use an unsupported option. Additionally, 3 of the notes are warning about the option only being available from PostgreSQL 9.6 and later. That version's support ended 2.5 years ago. So, it's quite clear that the value of these notes diminishes over time. Discussion: https://postgr.es/m/CAApHDvrCQn6tupx2R67VL9RP1Qy4dDuWKRvt4jaB0vk2akQchw@mail.gmail.com 
Here we remove the notes which mention which version the given vacuumdb
option is available from.  There are now 11 of these notes and they're
both quite untidy and take up far more space than they seem to be worth.
On running a print preview of the compiled HTML, removing these notes
saves about 1 A4 page (~20% less space).

If people need to see which options are available on older versions, then
consulting the documents for that version seems like a good idea.  In any
case, when using newer vacuumdb versions on older servers, the user will
receive an error if they try to use an unsupported option.

Additionally, 3 of the notes are warning about the option only being
available from PostgreSQL 9.6 and later.  That version's support ended 2.5
years ago.  So, it's quite clear that the value of these notes diminishes
over time.

Discussion: https://postgr.es/m/CAApHDvrCQn6tupx2R67VL9RP1Qy4dDuWKRvt4jaB0vk2akQchw@mail.gmail.com
Doc: add note about --buffer-usage-limit being v16 onwards 2023-04-16T09:47:01+00:00 David Rowley drowley@postgresql.org 2023-04-16T09:47:01+00:00 e9f451accbde17d106ac6a92c8877992d4410629 Other vacuumdb options seem to have notes about which version they're available from, so let's follow this trend for the newly added --buffer-usage-limit option. 
Other vacuumdb options seem to have notes about which version they're
available from, so let's follow this trend for the newly added
--buffer-usage-limit option.
Improve VACUUM/ANALYZE BUFFER_USAGE_LIMIT docs 2023-04-16T00:05:34+00:00 David Rowley drowley@postgresql.org 2023-04-16T00:05:34+00:00 c0235013c13b0adc9e7f1998ff5700e26ecdbd1f This addresses various deficiencies in the documentation for VACUUM and ANALYZE's BUFFER_USEAGE_LIMIT docs. Here we declare "size" in the syntax synopsis for VACUUM and ANALYZE's BUFFER_USAGE_LIMIT option and then define exactly what values can be specified for it in the section for that below. Also, fix the incorrect ordering of vacuumdb options both in the documents and in vacuumdb's --help output. These should be in alphabetical order. In passing also add the minimum/maximum range for the BUFFER_USAGE_LIMIT option. These will also serve as example values that can be modified and used. Reported-by: Peter Eisentraut Discussion: https://postgr.es/m/16845cb1-b228-e157-f293-5892bced9253@enterprisedb.com 
This addresses various deficiencies in the documentation for VACUUM and
ANALYZE's BUFFER_USEAGE_LIMIT docs.

Here we declare "size" in the syntax synopsis for VACUUM and ANALYZE's
BUFFER_USAGE_LIMIT option and then define exactly what values can be
specified for it in the section for that below.

Also, fix the incorrect ordering of vacuumdb options both in the documents
and in vacuumdb's --help output.  These should be in alphabetical order.

In passing also add the minimum/maximum range for the BUFFER_USAGE_LIMIT
option.  These will also serve as example values that can be modified and
used.

Reported-by: Peter Eisentraut
Discussion: https://postgr.es/m/16845cb1-b228-e157-f293-5892bced9253@enterprisedb.com
Revert "Catalog NOT NULL constraints" and fallout 2023-04-12T17:29:21+00:00 Alvaro Herrera alvherre@alvh.no-ip.org 2023-04-12T17:29:21+00:00 9ce04b50e120275afbc03ca0b80839dde3da8308 This reverts commit e056c557aef4 and minor later fixes thereof. There's a few problems in this new feature -- most notably regarding pg_upgrade behavior, but others as well. This new feature is not in any way critical on its own, so instead of scrambling to fix it we revert it and try again in early 17 with these issues in mind. Discussion: https://postgr.es/m/3801207.1681057430@sss.pgh.pa.us 
This reverts commit e056c557aef4 and minor later fixes thereof.

There's a few problems in this new feature -- most notably regarding
pg_upgrade behavior, but others as well.  This new feature is not in any
way critical on its own, so instead of scrambling to fix it we revert it
and try again in early 17 with these issues in mind.

Discussion: https://postgr.es/m/3801207.1681057430@sss.pgh.pa.us
doc: Fix some typos and grammar 2023-04-12T04:03:09+00:00 Michael Paquier michael@paquier.xyz 2023-04-12T04:03:09+00:00 644b848f50ef75430c0134654f86e8234691e390 This is a first batch of the fixes, for the most obvious fixes. A little bit more is under discussion. Author: Thom Brown, Justin Pryzby Discussion: https://postgr.es/m/CAA-aLv7xCZ0nBJa-NWe0rxBB28TjFjS2JtjiZMoQ+0wsugG+hQ@mail.gmail.com 
This is a first batch of the fixes, for the most obvious fixes.  A
little bit more is under discussion.

Author: Thom Brown, Justin Pryzby
Discussion: https://postgr.es/m/CAA-aLv7xCZ0nBJa-NWe0rxBB28TjFjS2JtjiZMoQ+0wsugG+hQ@mail.gmail.com
Doc: avoid using pg_get_publication_tables() in an example. 2023-04-10T16:22:10+00:00 Tom Lane tgl@sss.pgh.pa.us 2023-04-10T16:22:10+00:00 26f36fe844880ff68dc28493bba9aced5aad0034 pg_get_publication_tables() is undocumented because it's only meant as infrastructure for the pg_publication_tables system view. That being the case, we should use the view not the bare function in this sample query. Shi Yu Discussion: https://postgr.es/m/OSZPR01MB63107E83D07FEDEEABD83A23FD949@OSZPR01MB6310.jpnprd01.prod.outlook.com 
pg_get_publication_tables() is undocumented because it's only meant
as infrastructure for the pg_publication_tables system view.
That being the case, we should use the view not the bare function
in this sample query.

Shi Yu

Discussion: https://postgr.es/m/OSZPR01MB63107E83D07FEDEEABD83A23FD949@OSZPR01MB6310.jpnprd01.prod.outlook.com