[COMMITTERS] pgsql: Improve ALTER TABLE documentation

Improve ALTER TABLE documentation The ALTER TABLE documentation wasn't terribly clear when it came to which commands could be combined together and what it meant when they were. In particular, SET TABLESPACE *can* be combined with other commands, when it's operating against a single table, but

[COMMITTERS] pgsql: For 8.0 servers, get last built-in oid from pg_database

For 8.0 servers, get last built-in oid from pg_database We didn't start ensuring that all built-in objects had OIDs less than 16384 until 8.1, so for 8.0 servers we still need to query the value out of pg_database. We need this, in particular, to distinguish which casts were built-in and which

[COMMITTERS] pgsql: For 8.0 servers, get last built-in oid from pg_database

For 8.0 servers, get last built-in oid from pg_database We didn't start ensuring that all built-in objects had OIDs less than 16384 until 8.1, so for 8.0 servers we still need to query the value out of pg_database. We need this, in particular, to distinguish which casts were built-in and which

[COMMITTERS] pgsql: Fix dumping of casts and transforms using built-in functions

Fix dumping of casts and transforms using built-in functions In pg_dump.c dumpCast() and dumpTransform(), we would happily ignore the cast or transform if it happened to use a built-in function because we weren't including the information about built-in functions when querying pg_proc from

[COMMITTERS] pgsql: For 8.0 servers, get last built-in oid from pg_database

For 8.0 servers, get last built-in oid from pg_database We didn't start ensuring that all built-in objects had OIDs less than 16384 until 8.1, so for 8.0 servers we still need to query the value out of pg_database. We need this, in particular, to distinguish which casts were built-in and which

[COMMITTERS] pgsql: For 8.0 servers, get last built-in oid from pg_database

For 8.0 servers, get last built-in oid from pg_database We didn't start ensuring that all built-in objects had OIDs less than 16384 until 8.1, so for 8.0 servers we still need to query the value out of pg_database. We need this, in particular, to distinguish which casts were built-in and which

[COMMITTERS] pgsql: Fix dumping of casts and transforms using built-in functions

Fix dumping of casts and transforms using built-in functions In pg_dump.c dumpCast() and dumpTransform(), we would happily ignore the cast or transform if it happened to use a built-in function because we weren't including the information about built-in functions when querying pg_proc from

[COMMITTERS] pgsql: Fix dumping of casts and transforms using built-in functions

Fix dumping of casts and transforms using built-in functions In pg_dump.c dumpCast() and dumpTransform(), we would happily ignore the cast or transform if it happened to use a built-in function because we weren't including the information about built-in functions when querying pg_proc from

[COMMITTERS] pgsql: For 8.0 servers, get last built-in oid from pg_database

For 8.0 servers, get last built-in oid from pg_database We didn't start ensuring that all built-in objects had OIDs less than 16384 until 8.1, so for 8.0 servers we still need to query the value out of pg_database. We need this, in particular, to distinguish which casts were built-in and which

[COMMITTERS] pgsql: Fix dumping of casts and transforms using built-in functions

Fix dumping of casts and transforms using built-in functions In pg_dump.c dumpCast() and dumpTransform(), we would happily ignore the cast or transform if it happened to use a built-in function because we weren't including the information about built-in functions when querying pg_proc from

[COMMITTERS] pgsql: Fix dumping of casts and transforms using built-in functions

Fix dumping of casts and transforms using built-in functions In pg_dump.c dumpCast() and dumpTransform(), we would happily ignore the cast or transform if it happened to use a built-in function because we weren't including the information about built-in functions when querying pg_proc from

[COMMITTERS] pgsql: For 8.0 servers, get last built-in oid from pg_database

For 8.0 servers, get last built-in oid from pg_database We didn't start ensuring that all built-in objects had OIDs less than 16384 until 8.1, so for 8.0 servers we still need to query the value out of pg_database. We need this, in particular, to distinguish which casts were built-in and which

[COMMITTERS] pgsql: Fix dumping of casts and transforms using built-in functions

Fix dumping of casts and transforms using built-in functions In pg_dump.c dumpCast() and dumpTransform(), we would happily ignore the cast or transform if it happened to use a built-in function because we weren't including the information about built-in functions when querying pg_proc from

[COMMITTERS] pgsql: Silence compiler warnings

Silence compiler warnings Rearrange a bit of code to ensure that 'mode' in LWLockRelease is obviously always set, which seems a bit cleaner and avoids a compiler warning (thanks to Robert for the suggestion!). In GetCachedPlan(), initialize 'plan' to silence a compiler warning, but also add an

Re: [COMMITTERS] pgsql: Add support for restrictive RLS policies

Andres, * Andres Freund (and...@anarazel.de) wrote: > On 2016-12-05 20:51:02 +0000, Stephen Frost wrote: > > Add support for restrictive RLS policies > This is missing a catversion bump. Ewps, apologies and thanks for pointing it out. Fixed. Stephen signature.asc Descript

[COMMITTERS] pgsql: Bump catversion for restrictive RLS changes

Bump catversion for restrictive RLS changes Mea culpa. Pointed out by Andres. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/cb9dcbc1eebd8cccf98d7236b2c9bb82caf8b45d Modified Files -- src/include/catalog/catversion.h | 2 +- 1 file changed, 1

[COMMITTERS] pgsql: Add support for restrictive RLS policies

Add support for restrictive RLS policies We have had support for restrictive RLS policies since 9.5, but they were only available through extensions which use the appropriate hooks. This adds support into the grammer, catalog, psql and pg_dump for restrictive RLS policies, thus reducing the cases

[COMMITTERS] pgsql: Add --no-blobs option to pg_dump

Add --no-blobs option to pg_dump Add an option to exclude blobs when running pg_dump. By default, blobs are included but this option can be used to exclude them while keeping the rest of the dump. Commment updates and regression tests from me. Author: Guillaume Lelarge Reviewed-by: Amul Sul

[COMMITTERS] pgsql: Clarify pg_dump -b documentation

Clarify pg_dump -b documentation The documentation around the -b/--blobs option to pg_dump seemed to imply that it might be possible to add blobs to a "schema-only" dump or similar. Clarify that blobs are data and therefore will only be included in dumps where data is being included, even when

[COMMITTERS] pgsql: Clarify pg_dump -b documentation

Clarify pg_dump -b documentation The documentation around the -b/--blobs option to pg_dump seemed to imply that it might be possible to add blobs to a "schema-only" dump or similar. Clarify that blobs are data and therefore will only be included in dumps where data is being included, even when

[COMMITTERS] pgsql: Clarify pg_dump -b documentation

Clarify pg_dump -b documentation The documentation around the -b/--blobs option to pg_dump seemed to imply that it might be possible to add blobs to a "schema-only" dump or similar. Clarify that blobs are data and therefore will only be included in dumps where data is being included, even when

[COMMITTERS] pgsql: Clarify pg_dump -b documentation

Clarify pg_dump -b documentation The documentation around the -b/--blobs option to pg_dump seemed to imply that it might be possible to add blobs to a "schema-only" dump or similar. Clarify that blobs are data and therefore will only be included in dumps where data is being included, even when

[COMMITTERS] pgsql: Clarify pg_dump -b documentation

Clarify pg_dump -b documentation The documentation around the -b/--blobs option to pg_dump seemed to imply that it might be possible to add blobs to a "schema-only" dump or similar. Clarify that blobs are data and therefore will only be included in dumps where data is being included, even when

[COMMITTERS] pgsql: Clarify pg_dump -b documentation

Clarify pg_dump -b documentation The documentation around the -b/--blobs option to pg_dump seemed to imply that it might be possible to add blobs to a "schema-only" dump or similar. Clarify that blobs are data and therefore will only be included in dumps where data is being included, even when

[COMMITTERS] pgsql: Correct psql documentation example

Correct psql documentation example An example in the psql documentation had an incorrect field name from what the command actually produced. Pointed out by Fabien COELHO Back-patch to 9.6 where the example was added. Discussion: https://postgr.es/m/alpine.DEB.2.20.1611291349400.19314@lancre

[COMMITTERS] pgsql: Correct psql documentation example

Correct psql documentation example An example in the psql documentation had an incorrect field name from what the command actually produced. Pointed out by Fabien COELHO Back-patch to 9.6 where the example was added. Discussion: https://postgr.es/m/alpine.DEB.2.20.1611291349400.19314@lancre

[COMMITTERS] pgsql: Clean up pg_dump tests, re-enable BLOB testing

Clean up pg_dump tests, re-enable BLOB testing Add a loop to check that each test covers all of the pg_dump runs. We (I) had been a bit sloppy when adding new runs and not making sure to mark if they should be under like or unlike for each test, this loop makes sure that the test system will

[COMMITTERS] pgsql: Fix RLS with COPY (col1, col2) FROM tab

Fix RLS with COPY (col1, col2) FROM tab Attempting to COPY a subset of columns from a table with RLS enabled would fail due to an invalid query being constructed (using a single ColumnRef with the list of fields to exact in 'fields', but that's for the different levels of an indirection for a

[COMMITTERS] pgsql: Fix RLS with COPY (col1, col2) FROM tab

Fix RLS with COPY (col1, col2) FROM tab Attempting to COPY a subset of columns from a table with RLS enabled would fail due to an invalid query being constructed (using a single ColumnRef with the list of fields to exact in 'fields', but that's for the different levels of an indirection for a

[COMMITTERS] pgsql: Fix RLS with COPY (col1, col2) FROM tab

Fix RLS with COPY (col1, col2) FROM tab Attempting to COPY a subset of columns from a table with RLS enabled would fail due to an invalid query being constructed (using a single ColumnRef with the list of fields to exact in 'fields', but that's for the different levels of an indirection for a

Re: [COMMITTERS] pgsql: Separate enum from struct

Peter, * Peter Eisentraut (pete...@gmx.net) wrote: > Separate enum from struct > > Otherwise the enum symbols are not visible outside the struct in C++. > > Reviewed-by: Thomas Munro Looks like this upset the buildfarm pretty badly... Thanks! Stephen

[COMMITTERS] pgsql: Remove superuser checks in pgstattuple

Remove superuser checks in pgstattuple Now that we track initial privileges on extension objects and changes to those permissions, we can drop the superuser() checks from the various functions which are part of the pgstattuple extension and rely on the GRANT system to control access to those

[COMMITTERS] pgsql: Correctly handle owned sequences with extensions

Correctly handle owned sequences with extensions With the refactoring of pg_dump to handle components, getOwnedSeqs needs to be a bit more intelligent regarding which components to dump when. Specifically, we can't simply use the owning table's components as the set of components to dump as the

[COMMITTERS] pgsql: Add missing hyphen

Add missing hyphen Pointed out by Alexander Law Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/42ec6c2da699e8e0b1774988fa97297a2cdf716c Modified Files -- doc/src/sgml/runtime.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via

[COMMITTERS] pgsql: Typo fix, buils -> builds

Typo fix, buils -> builds Pointed out by Alexander Law. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/e8bde9e2538a25b4a5deea569c4c48244c1a7e40 Modified Files -- doc/src/sgml/install-windows.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[COMMITTERS] pgsql: Minor typos / copy-editing for snapmgr.c

Minor typos / copy-editing for snapmgr.c Noticed while reviewing snapshot management. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/40fc4575205dc563b88da1db9a8a75cc4d3b848a Modified Files -- src/backend/utils/time/snapmgr.c | 10 +- 1 file

[COMMITTERS] pgsql: pg_dump only selected components of ACCESS METHODs

pg_dump only selected components of ACCESS METHODs dumpAccessMethod() didn't get the memo that we now have a bitfield for the components which should be dumped instead of a simple boolean. Correct that by checking if the relevant bit is set for each component being dumped out (and not dumping it

[COMMITTERS] pgsql: Do not DROP default roles in pg_dumpall -c

Do not DROP default roles in pg_dumpall -c When pulling the list of roles to drop, exclude roles whose names begin with "pg_" (as we do when we are dumping the roles out to recreate them). Also add regression tests to cover pg_dumpall -c and this specific issue. Noticed by Rushabh Lathia.

[COMMITTERS] pgsql: Qualify table usage in dumpTable() and use regclass

Qualify table usage in dumpTable() and use regclass All of the other tables used in the query in dumpTable(), which is collecting column-level ACLs, are qualified, so we should be qualifying the pg_init_privs, the related sub-select against pg_class and the other queries added by the pg_dump

[COMMITTERS] pgsql: Wording quibbles regarding initdb username

Wording quibbles regarding initdb username Use disallowed instead of reserved, cannot instead of can not, and double quotes instead of single quotes. Also add a test to cover the bug which started this discussion. Per discussion with Tom. Branch -- master Details ---

[COMMITTERS] pgsql: Disallow superuser names starting with 'pg_' in initdb

Disallow superuser names starting with 'pg_' in initdb As with CREATE ROLE, disallow users from specifying initial superuser names which begin with 'pg_' in initdb. Per discussion with Tom. Branch -- master Details ---

[COMMITTERS] pgsql: Disable BLOB test in pg_dump TAP tests

Disable BLOB test in pg_dump TAP tests Buildfarm member jacana appears to have an issue with running this test. It's not entirely clear to me why, but rather than try to fight with it, just disable it for now. None of the other tests try to write out from psql directly as this test does, so it

[COMMITTERS] pgsql: Add test_pg_dump to @contrib_excludes

Add test_pg_dump to @contrib_excludes The test_pg_dump extension doesn't have a C component, so we need to exclude it from the MSVC build system trying to figure out how to build it. Also add a "MODULES" line to the Makefile, as test_extensions has. Might not be necessary, but seems good to keep

Re: [COMMITTERS] pgsql: Add TAP tests for pg_dump

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Stephen Frost (sfr...@snowman.net) wrote: > > > > The intagg contrib modules doesn't have a .c file either, nor a > > > MODULES_big line, and I don't see any errors with it. I'm not te

[COMMITTERS] pgsql: Correct query in pg_dumpall:dumpRoles

Correct query in pg_dumpall:dumpRoles We need to use a new branch due to the 9.5 addition of bypassrls when adding in the clause to exclude pg_* roles from being dumped by pg_dumpall. Pointed out by Noah, patch by me. Branch -- master Details ---

Re: [COMMITTERS] pgsql: Add TAP tests for pg_dump

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > * Stephen Frost (sfr...@snowman.net) wrote: > >> Looks like the test_pg_dump extension made the Windows builds upset. > >> I'm guessing that's because I set 'MODULES_big'

Re: [COMMITTERS] pgsql: Add TAP tests for pg_dump

* Stephen Frost (sfr...@snowman.net) wrote: > Alright, apparently that made other Windows buildfarm members unhappy... > > I guess the next approach will be to add back MODULES_big and add in a > .c file for the Windows systems to be happy about. I'm certainly open > to ot

Re: [COMMITTERS] pgsql: Add TAP tests for pg_dump

* Stephen Frost (sfr...@snowman.net) wrote: > * Stephen Frost (sfr...@snowman.net) wrote: > > src/test/modules/test_pg_dump/Makefile | 25 + > > src/test/modules/test_pg_dump/README |2 + > > .../modules/test_pg_dump/expected/test_pg_dump.out

[COMMITTERS] pgsql: Remove MODULES_big from test_pg_dump

Remove MODULES_big from test_pg_dump The Makefile for test_pg_dump shouldn't have a MODULES_big line because there's no actual compiled bit for that extension. Hopefully this will fix the Windows buildfarm members which were complaining. In passing, also add the 'prove_installcheck' bit to the

Re: [COMMITTERS] pgsql: Add TAP tests for pg_dump

* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 5/6/16 2:06 PM, Stephen Frost wrote: > >Add TAP tests for pg_dump > > I'd be the first to welcome this, but what happened to feature freeze? These are just new tests..? I assumed that would be welcome during post

Re: [COMMITTERS] pgsql: Add TAP tests for pg_dump

* Stephen Frost (sfr...@snowman.net) wrote: > src/test/modules/test_pg_dump/Makefile | 25 + > src/test/modules/test_pg_dump/README |2 + > .../modules/test_pg_dump/expected/test_pg_dump.out |6 + > src/test/modules/test_pg_dump/sql/test_pg_dump.sql |

[COMMITTERS] pgsql: Correct pg_dump WHERE clause for functions/aggregates

Correct pg_dump WHERE clause for functions/aggregates The query to grab the function/aggregate information is now joining to pg_init_privs, so we can simplify (and correct) the WHERE clause used to determine if a given function's ACL has changed from the initial ACL on the function. Bug found by

[COMMITTERS] pgsql: Add TAP tests for pg_dump

Add TAP tests for pg_dump This TAP test suite will create a new cluster, populate it based on the 'create_sql' values in the '%tests' hash, run all of the runs defined in the '%pgdump_runs' hash, and then for each test in the '%tests' hash, compare each run's output the the regular expression

[COMMITTERS] pgsql: pg_dump performance and other fixes

pg_dump performance and other fixes Do not try to dump objects which do not have ACLs when only ACLs are being requested. This results in a significant performance improvement as we can avoid querying for further information on these objects when we don't need to. When limiting the components

[COMMITTERS] pgsql: Only issue LOCK TABLE commands when necessary

Only issue LOCK TABLE commands when necessary Reviewing the cases where we need to LOCK a given table during a dump, it was pointed out by Tom that we really don't need to LOCK a table if we are only looking to dump the ACL for it, or certain other components. After reviewing the queries run for

[COMMITTERS] pgsql: Remove various special checks around default roles

Remove various special checks around default roles Default roles really should be like regular roles, for the most part. This removes a number of checks that were trying to make default roles extra special by not allowing them to be used as regular roles. We still prevent users from creating

Re: [COMMITTERS] pgsql: Reserve the "pg_" namespace for roles

Bruce, On Friday, April 29, 2016, Bruce Momjian <br...@momjian.us> wrote: > On Fri, Apr 8, 2016 at 08:56:34PM +, Stephen Frost wrote: > > Reserve the "pg_" namespace for roles > > > > This will prevent users from creating roles which begin with &qu

[COMMITTERS] pgsql: In recordExtensionInitPriv(), keep the scan til we're done with

In recordExtensionInitPriv(), keep the scan til we're done with it For reasons of sheer brain fade, we (I) was calling systable_endscan() immediately after systable_getnext() and expecting the tuple returned by systable_getnext() to still be valid. That's clearly wrong. Move the

Re: [COMMITTERS] pgsql: Fix pg_dump so pg_upgrade'ing an extension with simple opfamilie

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Tom Lane writes: > > Fix pg_dump so pg_upgrade'ing an extension with simple opfamilies works. > > I see this has broken the buildfarm's pg_upgrade checks, though only in > HEAD which makes me suspicious that it's exposing a

[COMMITTERS] pgsql: Disallow SET SESSION AUTHORIZATION pg_*

Disallow SET SESSION AUTHORIZATION pg_* As part of reserving the pg_* namespace for default roles and in line with SET ROLE and other previous efforts, disallow settings the role to a default/reserved role using SET SESSION AUTHORIZATION. These checks and restrictions on what is allowed

[COMMITTERS] pgsql: Correct copyright for newly added genericdesc.c

Correct copyright for newly added genericdesc.c It's 2016 these days (no, not entirely sure how we got here either). Pointed out by Amit Langote Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/cd13471f2e9dee6d411cae3ddae72d0ad6b58c4d Modified Files --

[COMMITTERS] pgsql: Prefix RLS regression test roles with 'regress_'

Prefix RLS regression test roles with 'regress_' To avoid any possible overlap with existing roles on a system when doing a 'make installcheck', use role names which start with 'regress_'. Pointed out by Tom. Branch -- master Details ---

[COMMITTERS] pgsql: Create default roles

Create default roles This creates an initial set of default roles which administrators may use to grant access to, historically, superuser-only functions. Using these roles instead of granting superuser access reduces the number of superuser roles required for a system. Documention for each of

[COMMITTERS] pgsql: Reserve the "pg_" namespace for roles

Reserve the "pg_" namespace for roles This will prevent users from creating roles which begin with "pg_" and will check for those roles before allowing an upgrade using pg_upgrade. This will allow for default roles to be provided at initdb time. Reviews by José Luis Tallón and Robert Haas

[COMMITTERS] pgsql: Fix improper usage of 'dump' bitmap

Fix improper usage of 'dump' bitmap Now that 'dump' is a bitmap, we can't simply set it to 'true'. Noticed while debugging the prior issue. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/fa6075e5515c6878b2c1fe1c6435dd7ed847857d Modified Files --

[COMMITTERS] pgsql: In dumpTable, re-instate the skipping logic

In dumpTable, re-instate the skipping logic Pretty sure I removed this based on some incorrect thinking that it was no longer possible to reach this point for a table which will not be dumped, but that's clearly wrong. Pointed out on IRC by Erik Rijkers. Branch -- master Details ---

Re: [COMMITTERS] pgsql: CREATE INDEX ... INCLUDING (column[, ...])

* Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Apr 8, 2016 at 2:29 PM, Tom Lane wrote: > > Teodor Sigaev writes: > >> CREATE INDEX ... INCLUDING (column[, ...]) > > > > Buildfarm members that don't like // comments are dying on this bit > > in

[COMMITTERS] pgsql: GRANT rights to CURRENT_USER instead of adding roles

GRANT rights to CURRENT_USER instead of adding roles We shouldn't be adding roles during the regression tests as that can cause back-to-back installcheck runs to fail and users running the regression tests likley don't want those extra roles. Pointed out by Tom Branch -- master Details

[COMMITTERS] pgsql: Bump catversion for pg_dump dump catalog ACL patches

Bump catversion for pg_dump dump catalog ACL patches Pointed out by Tom. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/29dd1504a12f324c75f6b5ce8863505e499633ec Modified Files -- src/include/catalog/catversion.h | 2 +- 1 file changed, 1 insertion(+), 1

Re: [COMMITTERS] pgsql: Use GRANT system to manage access to sensitive functions

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > Use GRANT system to manage access to sensitive functions > > This patch series seems approximately three catversion bumps > shy of a load ... Blargh. I told myself at three

[COMMITTERS] pgsql: In pg_dump, split "dump" into "dump" and "dump_contains"

In pg_dump, split "dump" into "dump" and "dump_contains" Historically, the "dump" component of the namespace has been used to decide if the objects inside of the namespace should be dumped also. Given that "dump" is now a bitmask and may be partial, and we may want to dump out all components of

[COMMITTERS] pgsql: Add new catalog called pg_init_privs

Add new catalog called pg_init_privs This new catalog holds the privileges which the system was initialized with at initdb time, along with any permissions set by extensions at CREATE EXTENSION time. This allows pg_dump (and any other similar use-cases) to detect when the privileges set on

[COMMITTERS] pgsql: In pg_dump, use a bitmap to represent what to include

In pg_dump, use a bitmap to represent what to include pg_dump has historically used a simple boolean 'dump' value to indicate if a given object should be included in the dump or not. Instead, use a bitmap which breaks down the components of an object into their distinct pieces and use that

[COMMITTERS] pgsql: In pg_dump, include pg_catalog and extension ACLs, if changed

In pg_dump, include pg_catalog and extension ACLs, if changed Now that all of the infrastructure exists, add in the ability to dump out the ACLs of the objects inside of pg_catalog or the ACLs for objects which are members of extensions, but only if they have been changed from their original

[COMMITTERS] pgsql: Use GRANT system to manage access to sensitive functions

Use GRANT system to manage access to sensitive functions Now that pg_dump will properly dump out any ACL changes made to functions which exist in pg_catalog, switch to using the GRANT system to manage access to those functions. This means removing 'if (!superuser()) ereport()' checks from the

[COMMITTERS] pgsql: Fix typo in pg_regress.c

Fix typo in pg_regress.c s/afer/after Pointed out by Andreas 'ads' Scherbaum Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/62b5cd234ba982f71f2501f405a26ed80c92a229 Modified Files -- src/test/regress/pg_regress.c | 2 +- 1 file changed, 1 insertion(+),

[COMMITTERS] pgsql: Reset plan->row_security_env and planUserId

Reset plan->row_security_env and planUserId In the plancache, we check if the environment we planned the query under has changed in a way which requires us to re-plan, such as when the user for whom the plan was prepared changes and RLS is being used (and, therefore, there may be different

[COMMITTERS] pgsql: Reset plan->row_security_env and planUserId

Reset plan->row_security_env and planUserId In the plancache, we check if the environment we planned the query under has changed in a way which requires us to re-plan, such as when the user for whom the plan was prepared changes and RLS is being used (and, therefore, there may be different

Re: [COMMITTERS] pgsql: Improve internationalization of messages involving type names

Alvaro, * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote: > Improve internationalization of messages involving type names > > Change the slightly different variations of the message > function FOO must return type BAR > to a single wording, removing the variability in type name so that they >

[COMMITTERS] pgsql: Avoid incorrectly indicating exclusion constraint wait

Avoid incorrectly indicating exclusion constraint wait INSERT ... ON CONFLICT's precheck may have to wait on the outcome of another insertion, which may or may not itself be a speculative insertion. This wait is not necessarily associated with an exclusion constraint, but was always reported

[COMMITTERS] pgsql: Avoid incorrectly indicating exclusion constraint wait

Avoid incorrectly indicating exclusion constraint wait INSERT ... ON CONFLICT's precheck may have to wait on the outcome of another insertion, which may or may not itself be a speculative insertion. This wait is not necessarily associated with an exclusion constraint, but was always reported

[COMMITTERS] pgsql: Make viewquery a copy in rewriteTargetView()

Make viewquery a copy in rewriteTargetView() Rather than expect the Query returned by get_view_query() to be read-only and then copy bits and pieces of it out, simply copy the entire structure when we get it. This addresses an issue where AcquireRewriteLocks, which is called by

[COMMITTERS] pgsql: Make viewquery a copy in rewriteTargetView()

Make viewquery a copy in rewriteTargetView() Rather than expect the Query returned by get_view_query() to be read-only and then copy bits and pieces of it out, simply copy the entire structure when we get it. This addresses an issue where AcquireRewriteLocks, which is called by

[COMMITTERS] pgsql: Make viewquery a copy in rewriteTargetView()

Make viewquery a copy in rewriteTargetView() Rather than expect the Query returned by get_view_query() to be read-only and then copy bits and pieces of it out, simply copy the entire structure when we get it. This addresses an issue where AcquireRewriteLocks, which is called by

[COMMITTERS] pgsql: Make viewquery a copy in rewriteTargetView()

Make viewquery a copy in rewriteTargetView() Rather than expect the Query returned by get_view_query() to be read-only and then copy bits and pieces of it out, simply copy the entire structure when we get it. This addresses an issue where AcquireRewriteLocks, which is called by

[COMMITTERS] pgsql: Improve CREATE POLICY documentation

Improve CREATE POLICY documentation Clarify that SELECT policies are now applied when SELECT rights are required for a given query, even if the query is an UPDATE or DELETE query. Pointed out by Noah. Additionally, note the risk regarding concurrently open transactions where a relation which

[COMMITTERS] pgsql: Improve CREATE POLICY documentation

Improve CREATE POLICY documentation Clarify that SELECT policies are now applied when SELECT rights are required for a given query, even if the query is an UPDATE or DELETE query. Pointed out by Noah. Additionally, note the risk regarding concurrently open transactions where a relation which

[COMMITTERS] pgsql: Collect the global OR of hasRowSecurity flags for plancache

Collect the global OR of hasRowSecurity flags for plancache We carry around information about if a given query has row security or not to allow the plancache to use that information to invalidate a planned query in the event that the environment changes. Previously, the flag of one of the

[COMMITTERS] pgsql: Collect the global OR of hasRowSecurity flags for plancache

Collect the global OR of hasRowSecurity flags for plancache We carry around information about if a given query has row security or not to allow the plancache to use that information to invalidate a planned query in the event that the environment changes. Previously, the flag of one of the

[COMMITTERS] pgsql: Handle policies during DROP OWNED BY

Handle policies during DROP OWNED BY DROP OWNED BY handled GRANT-based ACLs but was not removing roles from policies. Fix that by having DROP OWNED BY remove the role specified from the list of roles the policy (or policies) apply to, or the entire policy (or policies) if it only applied to the

[COMMITTERS] pgsql: Handle policies during DROP OWNED BY

Handle policies during DROP OWNED BY DROP OWNED BY handled GRANT-based ACLs but was not removing roles from policies. Fix that by having DROP OWNED BY remove the role specified from the list of roles the policy (or policies) apply to, or the entire policy (or policies) if it only applied to the

[COMMITTERS] pgsql: Handle dependencies properly in ALTER POLICY

Handle dependencies properly in ALTER POLICY ALTER POLICY hadn't fully considered partial policy alternation (eg: change just the roles on the policy, or just change one of the expressions) when rebuilding the dependencies. Instead, it would happily remove all dependencies which existed for the

[COMMITTERS] pgsql: Handle dependencies properly in ALTER POLICY

Handle dependencies properly in ALTER POLICY ALTER POLICY hadn't fully considered partial policy alternation (eg: change just the roles on the policy, or just change one of the expressions) when rebuilding the dependencies. Instead, it would happily remove all dependencies which existed for the

Re: [COMMITTERS] pgsql: Improve pageinspect module

* Teodor Sigaev (teo...@sigaev.ru) wrote: > Improve pageinspect module > > Now pageinspect can show data stored in the heap tuple. The buildfarm isn't happy with this change.. Thanks! Stephen signature.asc Description: Digital signature

[COMMITTERS] pgsql: Correct sepgsql docs with regard to RLS

Correct sepgsql docs with regard to RLS The sepgsql docs included a comment that PG doesn't support RLS. That is only true for versions prior to 9.5. Update the docs for 9.5 and master to say that PG supports RLS but that sepgsql does not yet. Pointed out by Heikki. Back-patch to 9.5 Branch

[COMMITTERS] pgsql: Correct sepgsql docs with regard to RLS

Correct sepgsql docs with regard to RLS The sepgsql docs included a comment that PG doesn't support RLS. That is only true for versions prior to 9.5. Update the docs for 9.5 and master to say that PG supports RLS but that sepgsql does not yet. Pointed out by Heikki. Back-patch to 9.5 Branch

[COMMITTERS] pgsql: Set include_realm=1 default in parse_hba_line

Set include_realm=1 default in parse_hba_line With include_realm=1 being set down in parse_hba_auth_opt, if multiple options are passed on the pg_hba line, such as: host all all0.0.0.0/0gss include_realm=0 krb_realm=XYZ.COM We would mistakenly reset include_realm back to 1.

[COMMITTERS] pgsql: Set include_realm=1 default in parse_hba_line

Set include_realm=1 default in parse_hba_line With include_realm=1 being set down in parse_hba_auth_opt, if multiple options are passed on the pg_hba line, such as: host all all0.0.0.0/0gss include_realm=0 krb_realm=XYZ.COM We would mistakenly reset include_realm back to 1.

[COMMITTERS] pgsql: Handle append_rel_list in expand_security_qual

Handle append_rel_list in expand_security_qual During expand_security_quals, we take the security barrier quals on an RTE and create a subquery which evaluates the quals. During this, we have to replace any variables in the outer query which refer to the original RTE with references to the

[COMMITTERS] pgsql: Handle append_rel_list in expand_security_qual

Handle append_rel_list in expand_security_qual During expand_security_quals, we take the security barrier quals on an RTE and create a subquery which evaluates the quals. During this, we have to replace any variables in the outer query which refer to the original RTE with references to the

<    1   2   3   4   5   >