pgsql: Doc: sync CREATE GROUP syntax synopsis with CREATE ROLE.
Doc: sync CREATE GROUP syntax synopsis with CREATE ROLE. CREATE GROUP is an exact alias for CREATE ROLE, and CREATE USER is almost an exact alias, as can easily be confirmed by checking the code. So the man page syntax descriptions ought to match up. The last few additions of role options seem to have forgotten to update create_group.sgml, though. Fix that, and add a naggy reminder to create_role.sgml in hopes of not forgetting again. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7b99e46742fc93e0cd8d48b0eec55eca1a7b2790 Modified Files -- doc/src/sgml/ref/create_group.sgml | 3 +++ 1 file changed, 3 insertions(+)
pgsql: Doc: sync CREATE GROUP syntax synopsis with CREATE ROLE.
Doc: sync CREATE GROUP syntax synopsis with CREATE ROLE. CREATE GROUP is an exact alias for CREATE ROLE, and CREATE USER is almost an exact alias, as can easily be confirmed by checking the code. So the man page syntax descriptions ought to match up. The last few additions of role options seem to have forgotten to update create_group.sgml, though. Fix that, and add a naggy reminder to create_role.sgml in hopes of not forgetting again. Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8f50e68a0560dae67dda628296d5a26817b7 Modified Files -- doc/src/sgml/ref/create_group.sgml | 3 +++ 1 file changed, 3 insertions(+)
pgsql: Doc: sync CREATE GROUP syntax synopsis with CREATE ROLE.
Doc: sync CREATE GROUP syntax synopsis with CREATE ROLE. CREATE GROUP is an exact alias for CREATE ROLE, and CREATE USER is almost an exact alias, as can easily be confirmed by checking the code. So the man page syntax descriptions ought to match up. The last few additions of role options seem to have forgotten to update create_group.sgml, though. Fix that, and add a naggy reminder to create_role.sgml in hopes of not forgetting again. Discussion: https://postgr.es/m/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/21b74a17c8ab316cbd696f4d467ccc42985a72de Modified Files -- doc/src/sgml/ref/create_group.sgml | 5 - doc/src/sgml/ref/create_role.sgml | 5 + 2 files changed, 9 insertions(+), 1 deletion(-)
pgsql: Doc: sync CREATE GROUP syntax synopsis with CREATE ROLE.
Doc: sync CREATE GROUP syntax synopsis with CREATE ROLE. CREATE GROUP is an exact alias for CREATE ROLE, and CREATE USER is almost an exact alias, as can easily be confirmed by checking the code. So the man page syntax descriptions ought to match up. The last few additions of role options seem to have forgotten to update create_group.sgml, though. Fix that, and add a naggy reminder to create_role.sgml in hopes of not forgetting again. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b75aa49bb8cbc96fc741791bc021a83a697a1307 Modified Files -- doc/src/sgml/ref/create_group.sgml | 5 - doc/src/sgml/ref/create_role.sgml | 5 + 2 files changed, 9 insertions(+), 1 deletion(-)
pgsql: Doc: sync CREATE GROUP syntax synopsis with CREATE ROLE.
Doc: sync CREATE GROUP syntax synopsis with CREATE ROLE. CREATE GROUP is an exact alias for CREATE ROLE, and CREATE USER is almost an exact alias, as can easily be confirmed by checking the code. So the man page syntax descriptions ought to match up. The last few additions of role options seem to have forgotten to update create_group.sgml, though. Fix that, and add a naggy reminder to create_role.sgml in hopes of not forgetting again. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/89e54113416018ad5fadeeca8e009a2e1dc233cd Modified Files -- doc/src/sgml/ref/create_group.sgml | 3 +++ 1 file changed, 3 insertions(+)
pgsql: Doc: sync CREATE GROUP syntax synopsis with CREATE ROLE.
Doc: sync CREATE GROUP syntax synopsis with CREATE ROLE. CREATE GROUP is an exact alias for CREATE ROLE, and CREATE USER is almost an exact alias, as can easily be confirmed by checking the code. So the man page syntax descriptions ought to match up. The last few additions of role options seem to have forgotten to update create_group.sgml, though. Fix that, and add a naggy reminder to create_role.sgml in hopes of not forgetting again. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7c91e9055d254524d76a72b35a919b8ff9931802 Modified Files -- doc/src/sgml/ref/create_group.sgml | 5 - doc/src/sgml/ref/create_role.sgml | 5 + 2 files changed, 9 insertions(+), 1 deletion(-)
Re: pgsql: Remove testing for precise LSN/reserved bytes in new TAP test
On 2020-Apr-10, Kyotaro Horiguchi wrote: > > Yeah. We have at least four different buildfarm members complaining > > about this test case. I took this patch and further lobotomized the > > tests by removing *all* dependencies on restart_lsn and > > pg_current_wal_lsn(). If anybody wants to put any of that back, > > the burden of proof will be on them to show why we should believe > > the results will be stable, not for the buildfarm to demonstrate > > that they're not. > > I think the significant part of the test is wal_status. So I'm not > eager to get it back. Agreed. Thanks for stabilizing it. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: pgsql: doc: add examples of creative use of unique expression indexes
Bruce Momjian writes: > doc: add examples of creative use of unique expression indexes > https://git.postgresql.org/pg/commitdiff/a9760d0f3cb523336b5fdd9d6c5985e39a8588a1 We had a complaint [1] that this dropped an example into the middle of two related paragraphs. I agree with that objection, and also notice that the extra example broke subsequent references to the "first example" and "second example". I'm also unhappy that the other addition that this commit made was dropped inside Example 11.3; if we're going to use markup at all, each one ought to be a coherent entity. On top of that, I don't find that either example actually adds anything to the discussion, as the same points are being made in the existing text. Therefore, I don't think it's worth trying to fix these problems, and propose just reverting this patch. regards, tom lane [1] https://www.postgresql.org/message-id/158648685043.655.3074746555320970574%40wrigleys.postgresql.org
pgsql: Suppress unused-variable warning.
Suppress unused-variable warning. Ashutosh Bapat Discussion: https://postgr.es/m/CAG-ACPWPB8Lc_aFj25eiPFqi31YB5vmaZnb39mbHSf5Yej=m...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/401418ca6a689f772cbfa1aedc7485cbbcde7a94 Modified Files -- src/backend/partitioning/partbounds.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
pgsql: Doc: clarify locking requirements for ALTER TABLE ADD FOREIGN KE
Doc: clarify locking requirements for ALTER TABLE ADD FOREIGN KEY. The docs explained that a SHARE ROW EXCLUSIVE lock is needed on the referenced table, but failed to say the same about the table being altered. Since the page says that ACCESS EXCLUSIVE lock is taken unless otherwise stated, this left readers with the wrong conclusion. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2cab4ad81bcb44ccd6591ed1fb54495c7301b42d Modified Files -- doc/src/sgml/ref/alter_table.sgml | 21 - 1 file changed, 16 insertions(+), 5 deletions(-)
pgsql: Doc: clarify locking requirements for ALTER TABLE ADD FOREIGN KE
Doc: clarify locking requirements for ALTER TABLE ADD FOREIGN KEY. The docs explained that a SHARE ROW EXCLUSIVE lock is needed on the referenced table, but failed to say the same about the table being altered. Since the page says that ACCESS EXCLUSIVE lock is taken unless otherwise stated, this left readers with the wrong conclusion. Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/61a9b814c553439854e9515ecb6458f77402443a Modified Files -- doc/src/sgml/ref/alter_table.sgml | 21 - 1 file changed, 16 insertions(+), 5 deletions(-)
pgsql: Doc: clarify locking requirements for ALTER TABLE ADD FOREIGN KE
Doc: clarify locking requirements for ALTER TABLE ADD FOREIGN KEY. The docs explained that a SHARE ROW EXCLUSIVE lock is needed on the referenced table, but failed to say the same about the table being altered. Since the page says that ACCESS EXCLUSIVE lock is taken unless otherwise stated, this left readers with the wrong conclusion. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1d676ffd41be443d0c7a715f3e03841430ba4a2b Modified Files -- doc/src/sgml/ref/alter_table.sgml | 21 - 1 file changed, 16 insertions(+), 5 deletions(-)
pgsql: Doc: clarify locking requirements for ALTER TABLE ADD FOREIGN KE
Doc: clarify locking requirements for ALTER TABLE ADD FOREIGN KEY. The docs explained that a SHARE ROW EXCLUSIVE lock is needed on the referenced table, but failed to say the same about the table being altered. Since the page says that ACCESS EXCLUSIVE lock is taken unless otherwise stated, this left readers with the wrong conclusion. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/aa4416dcd924a49e766baae9c73e884249d687d0 Modified Files -- doc/src/sgml/ref/alter_table.sgml | 21 + 1 file changed, 13 insertions(+), 8 deletions(-)
pgsql: Doc: clarify locking requirements for ALTER TABLE ADD FOREIGN KE
Doc: clarify locking requirements for ALTER TABLE ADD FOREIGN KEY. The docs explained that a SHARE ROW EXCLUSIVE lock is needed on the referenced table, but failed to say the same about the table being altered. Since the page says that ACCESS EXCLUSIVE lock is taken unless otherwise stated, this left readers with the wrong conclusion. Discussion: https://postgr.es/m/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a88e5886c59c0e1e01f424a1fcb477db82ddd3af Modified Files -- doc/src/sgml/ref/alter_table.sgml | 21 + 1 file changed, 13 insertions(+), 8 deletions(-)
pgsql: Doc: clarify locking requirements for ALTER TABLE ADD FOREIGN KE
Doc: clarify locking requirements for ALTER TABLE ADD FOREIGN KEY. The docs explained that a SHARE ROW EXCLUSIVE lock is needed on the referenced table, but failed to say the same about the table being altered. Since the page says that ACCESS EXCLUSIVE lock is taken unless otherwise stated, this left readers with the wrong conclusion. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f333d35428c1cba8d35065b6dbb2dd46e18bd929 Modified Files -- doc/src/sgml/ref/alter_table.sgml | 21 + 1 file changed, 13 insertions(+), 8 deletions(-)
Re: pgsql: doc: add examples of creative use of unique expression indexes
On Fri, Apr 10, 2020 at 11:30:34AM -0400, Tom Lane wrote: > Bruce Momjian writes: > > doc: add examples of creative use of unique expression indexes > > https://git.postgresql.org/pg/commitdiff/a9760d0f3cb523336b5fdd9d6c5985e39a8588a1 > > We had a complaint [1] that this dropped an example into the middle of > two related paragraphs. I agree with that objection, and also notice > that the extra example broke subsequent references to the "first example" > and "second example". I'm also unhappy that the other addition that this > commit made was dropped inside Example 11.3; if we're going to use > markup at all, each one ought to be a coherent entity. > > On top of that, I don't find that either example actually adds anything > to the discussion, as the same points are being made in the existing > text. Therefore, I don't think it's worth trying to fix these problems, > and propose just reverting this patch. > > regards, tom lane > > [1] > https://www.postgresql.org/message-id/158648685043.655.3074746555320970574%40wrigleys.postgresql.org I agree with your analysis. I still want to have some mention that partial indexes can be used to create single-NULL columns, which might be required for compatibility with other databases. Attached is an updated patch which removes the previous commit but adds a mention of this. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + diff --git a/doc/src/sgml/indices.sgml b/doc/src/sgml/indices.sgml index 1be209a2fe..3a8f93bac7 100644 --- a/doc/src/sgml/indices.sgml +++ b/doc/src/sgml/indices.sgml @@ -705,15 +705,6 @@ CREATE INDEX test1_lower_col1_idx ON test1 (lower(col1)); - - Expression indexes also allow control over the scope of unique indexes. - For example, this unique index prevents duplicate integer values from - being stored in a double precision-typed column: - -CREATE UNIQUE INDEX test1_uniq_int ON tests ((floor(double_col))) - - - If we were to declare this index UNIQUE, it would prevent creation of rows whose col1 values differ only in case, @@ -953,17 +944,9 @@ CREATE UNIQUE INDEX tests_success_constraint ON tests (subject, target) WHERE success; This is a particularly efficient approach when there are few -successful tests and many unsuccessful ones. - - - -This index allows only one null in the indexed column by using a -partial index clause to process only null column values, and using -an expression index clause to index true instead -of null: - -CREATE UNIQUE INDEX tests_target_one_null ON tests ((target IS NULL)) WHERE target IS NULL; - +successful tests and many unsuccessful ones. Creating a unique +index with an IS NULL qualification can restrict +a column to a single NULL value.
Re: pgsql: doc: add examples of creative use of unique expression indexes
Bruce Momjian writes: > I agree with your analysis. I still want to have some mention that > partial indexes can be used to create single-NULL columns, which might > be required for compatibility with other databases. Attached is an > updated patch which removes the previous commit but adds a mention of > this. The single-null thing is probably a useful example, but please make it an actual separate example, or at least its own para outside the existing sections. Also, the existing example demonstrating that seems overcomplicated; why not just create unique index ... (1) where (foo is null); regards, tom lane
pgsql: Add contrib/amcheck debug message.
Add contrib/amcheck debug message. Add a DEBUG1 message indicating that verification of the index structure is underway. Also reduce the severity level of the existing "tree level" debug message to DEBUG1. It should never have been made DEBUG2. Any B-Tree index with more than a couple of levels will generally also have so many pages that the per-page DEBUG2 messages will become completely unmanageable. In passing, add a new "Tip" to the docs that advises users that run into corruption that the debug messages might provide useful additional context. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/20fbb711ef43ef70093378ff5efdf1b6e8cc10d8 Modified Files -- contrib/amcheck/verify_nbtree.c | 9 - doc/src/sgml/amcheck.sgml | 21 + 2 files changed, 29 insertions(+), 1 deletion(-)
Re: pgsql: doc: add examples of creative use of unique expression indexes
On Fri, Apr 10, 2020 at 07:21:29PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > I agree with your analysis. I still want to have some mention that > > partial indexes can be used to create single-NULL columns, which might > > be required for compatibility with other databases. Attached is an > > updated patch which removes the previous commit but adds a mention of > > this. > > The single-null thing is probably a useful example, but please make > it an actual separate example, or at least its own para outside the > existing sections. > > Also, the existing example demonstrating that seems overcomplicated; > why not just > > create unique index ... (1) where (foo is null); I ended up using "true" since that is ony one byte; patch attached. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + diff --git a/doc/src/sgml/indices.sgml b/doc/src/sgml/indices.sgml index 1be209a2fe..e8205a07b5 100644 --- a/doc/src/sgml/indices.sgml +++ b/doc/src/sgml/indices.sgml @@ -705,15 +705,6 @@ CREATE INDEX test1_lower_col1_idx ON test1 (lower(col1)); - - Expression indexes also allow control over the scope of unique indexes. - For example, this unique index prevents duplicate integer values from - being stored in a double precision-typed column: - -CREATE UNIQUE INDEX test1_uniq_int ON tests ((floor(double_col))) - - - If we were to declare this index UNIQUE, it would prevent creation of rows whose col1 values differ only in case, @@ -956,16 +947,17 @@ CREATE UNIQUE INDEX tests_success_constraint ON tests (subject, target) successful tests and many unsuccessful ones. - -This index allows only one null in the indexed column by using a -partial index clause to process only null column values, and using -an expression index clause to index true instead -of null: + + + + This index allows only one null in the indexed column by using a + partial index clause to process only null column values, and using + an expression index clause to index true instead + of null: -CREATE UNIQUE INDEX tests_target_one_null ON tests ((target IS NULL)) WHERE target IS NULL; +CREATE UNIQUE INDEX tests_target_one_null ON tests ((true)) WHERE target IS NULL; - - + Finally, a partial index can also be used to override the system's
