pgsql: Restrict access to reindex of shared catalogs for non-privileged

Restrict access to reindex of shared catalogs for non-privileged users A database owner running a database-level REINDEX has the possibility to also do the operation on shared system catalogs without being an owner of them, which allows him to block resources it should not have access to. The sam

pgsql: Restrict access to reindex of shared catalogs for non-privileged

Restrict access to reindex of shared catalogs for non-privileged users A database owner running a database-level REINDEX has the possibility to also do the operation on shared system catalogs without being an owner of them, which allows him to block resources it should not have access to. The sam

pgsql: Spell "partitionwise" consistently.

Spell "partitionwise" consistently. I'm not sure which spelling is better, "partitionwise" or "partition-wise", but everywhere else we spell it "partitionwise", so be consistent. Tatsuro Yamada reported the one in README, I found the other one with grep. Discussion: https://www.postgresql.org/m

pgsql: Spell "partitionwise" consistently.

Spell "partitionwise" consistently. I'm not sure which spelling is better, "partitionwise" or "partition-wise", but everywhere else we spell it "partitionwise", so be consistent. Tatsuro Yamada reported the one in README, I found the other one with grep. Discussion: https://www.postgresql.org/m

pgsql: Fix failure to reset libpq's state fully between connection atte

Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of

pgsql: Fix failure to reset libpq's state fully between connection atte

Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of

pgsql: Fix failure to reset libpq's state fully between connection atte

Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of

pgsql: Fix failure to reset libpq's state fully between connection atte

Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of

pgsql: Fix failure to reset libpq's state fully between connection atte

Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of

pgsql: Last-minute updates for release notes.

Last-minute updates for release notes. Security: CVE-2018-10915, CVE-2018-10925 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/749839c4d53c60de2e51ef82a03f1084e3ec1f6c Modified Files -- doc/src/sgml/release-10.sgml | 90

pgsql: Fix failure to reset libpq's state fully between connection atte

Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of

pgsql: Last-minute updates for release notes.

Last-minute updates for release notes. Security: CVE-2018-10915, CVE-2018-10925 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/cd2490789e82d9cc0cc5a23e666394f21d0b498f Modified Files -- doc/src/sgml/release-9.3.sgml | 28 +++ doc/

pgsql: Last-minute updates for release notes.

Last-minute updates for release notes. Security: CVE-2018-10915, CVE-2018-10925 Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c54f04820a48c33ca15b24552eab29f5137ce462 Modified Files -- doc/src/sgml/release-9.3.sgml | 28

pgsql: Last-minute updates for release notes.

Last-minute updates for release notes. Security: CVE-2018-10915, CVE-2018-10925 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3fd77b1dccb8539d68a517711bfd29310ecc4c04 Modified Files -- doc/src/sgml/release-9.3.sgml | 28 +++ doc/

pgsql: Fix failure to reset libpq's state fully between connection atte

Fix failure to reset libpq's state fully between connection attempts. The logic in PQconnectPoll() did not take care to ensure that all of a PGconn's internal state variables were reset before trying a new connection attempt. If we got far enough in the connection sequence to have changed any of

pgsql: Last-minute updates for release notes.

Last-minute updates for release notes. Security: CVE-2018-10915, CVE-2018-10925 Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ebeb8d53710ea140dd00eb6506cbe50db4e11dce Modified Files -- doc/src/sgml/release-9.3.sgml | 28

pgsql: Last-minute updates for release notes.

Last-minute updates for release notes. Security: CVE-2018-10915, CVE-2018-10925 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9d3072d2db2edbc19603d8d65189a504cc4e4712 Modified Files -- doc/src/sgml/release-10.sgml | 90

pgsql: Last-minute updates for release notes.

Last-minute updates for release notes. Security: CVE-2018-10915, CVE-2018-10925 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e0ee93053998b159e395deed7c42e02b1f921552 Modified Files -- doc/src/sgml/release-10.sgml | 90 +++

pgsql: docs: Only first instance of a PREPARE parameter sets data type

docs: Only first instance of a PREPARE parameter sets data type If the first reference to $1 is "($1 = col) or ($1 is null)", the data type can be determined, but not for "($1 is null) or ($1 = col)". This change documents this. Reported-by: Morgan Owens Discussion: https://postgr.es/m/153233

pgsql: docs: Only first instance of a PREPARE parameter sets data type

docs: Only first instance of a PREPARE parameter sets data type If the first reference to $1 is "($1 = col) or ($1 is null)", the data type can be determined, but not for "($1 is null) or ($1 = col)". This change documents this. Reported-by: Morgan Owens Discussion: https://postgr.es/m/153233

pgsql: docs: Only first instance of a PREPARE parameter sets data type

docs: Only first instance of a PREPARE parameter sets data type If the first reference to $1 is "($1 = col) or ($1 is null)", the data type can be determined, but not for "($1 is null) or ($1 = col)". This change documents this. Reported-by: Morgan Owens Discussion: https://postgr.es/m/153233

pgsql: docs: Only first instance of a PREPARE parameter sets data type

docs: Only first instance of a PREPARE parameter sets data type If the first reference to $1 is "($1 = col) or ($1 is null)", the data type can be determined, but not for "($1 is null) or ($1 = col)". This change documents this. Reported-by: Morgan Owens Discussion: https://postgr.es/m/153233

pgsql: docs: Only first instance of a PREPARE parameter sets data type

docs: Only first instance of a PREPARE parameter sets data type If the first reference to $1 is "($1 = col) or ($1 is null)", the data type can be determined, but not for "($1 is null) or ($1 = col)". This change documents this. Reported-by: Morgan Owens Discussion: https://postgr.es/m/153233

pgsql: docs: Only first instance of a PREPARE parameter sets data type

docs: Only first instance of a PREPARE parameter sets data type If the first reference to $1 is "($1 = col) or ($1 is null)", the data type can be determined, but not for "($1 is null) or ($1 = col)". This change documents this. Reported-by: Morgan Owens Discussion: https://postgr.es/m/153233

pgsql: docs: Only first instance of a PREPARE parameter sets data type

docs: Only first instance of a PREPARE parameter sets data type If the first reference to $1 is "($1 = col) or ($1 is null)", the data type can be determined, but not for "($1 is null) or ($1 = col)". This change documents this. Reported-by: Morgan Owens Discussion: https://postgr.es/m/153233

pgsql: Document need to clear MAKELEVEL when invoking PG build from a m

Document need to clear MAKELEVEL when invoking PG build from a makefile. Since commit 3b8f6e75f, failure to do this would lead to submake-generated-headers not doing anything, so that references to generated or symlinked headers would fail. Previous to that, the omission only led to temp-install

pgsql: Document need to clear MAKELEVEL when invoking PG build from a m

Document need to clear MAKELEVEL when invoking PG build from a makefile. Since commit 3b8f6e75f, failure to do this would lead to submake-generated-headers not doing anything, so that references to generated or symlinked headers would fail. Previous to that, the omission only led to temp-install

pgsql: Add RECURSIVE to documentation index

Add RECURSIVE to documentation index Author: Daniel Vérité Reviewed-by: Fabien COELHO Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/58a36f91b36f30603e5983f19d26c67941ce

pgsql: Add RECURSIVE to documentation index

Add RECURSIVE to documentation index Author: Daniel Vérité Reviewed-by: Fabien COELHO Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a5db27418e222a930cd39f48907e58a13837b331 M