[COMMITTERS] Migration to pglister - Before

Greetings, We will be migrating these lists to pglister in the next few minutes. This final email on the old list system is intended to let you know that future emails will have different headers and you will need to adjust your filters. The changes which we expect to be most significant to

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Andres Freund writes: > > Do we care about people upgrading to unreleased versions? We could do > > nothing, document it in the release notes, or ??? > > Do nothing. Agreed. Not much we can do there. Thanks! Stephen signature.asc

[COMMITTERS] pgsql: Remove inbound links to sql-createuser

Remove inbound links to sql-createuser CREATE USER is an alias for CREATE ROLE, not its own command any longer, so clean up references to the 'sql-createuser' link to go to 'sql-createrole' instead. In passing, change a few cases of 'CREATE USER' to be 'CREATE ROLE ... LOGIN'. The remaining

[COMMITTERS] pgsql: Fix ordering in pg_dump of GRANTs

Fix ordering in pg_dump of GRANTs The order in which GRANTs are output is important as GRANTs which have been GRANT'd by individuals via WITH GRANT OPTION GRANTs have to come after the GRANT which included the WITH GRANT OPTION. This happens naturally in the backend during normal operation as we

[COMMITTERS] pgsql: Fix ordering in pg_dump of GRANTs

Fix ordering in pg_dump of GRANTs The order in which GRANTs are output is important as GRANTs which have been GRANT'd by individuals via WITH GRANT OPTION GRANTs have to come after the GRANT which included the WITH GRANT OPTION. This happens naturally in the backend during normal operation as we

[COMMITTERS] pgsql: Fix ordering in pg_dump of GRANTs

Fix ordering in pg_dump of GRANTs The order in which GRANTs are output is important as GRANTs which have been GRANT'd by individuals via WITH GRANT OPTION GRANTs have to come after the GRANT which included the WITH GRANT OPTION. This happens naturally in the backend during normal operation as we

[COMMITTERS] pgsql: psql: Fix \gx when FETCH_COUNT is used

psql: Fix \gx when FETCH_COUNT is used Set expanded output when requested through \gx in ExecQueryUsingCursor() (used when FETCH_COUNT is set). Discussion: https://www.postgresql.org/message-id/CB7A53AA-5645-4BDD-AB07-4D22CD9D8FF1%40gmx.net Author: Tobias Bussmann Branch -- REL_10_STABLE

[COMMITTERS] pgsql: psql: Fix \gx when FETCH_COUNT is used

psql: Fix \gx when FETCH_COUNT is used Set expanded output when requested through \gx in ExecQueryUsingCursor() (used when FETCH_COUNT is set). Discussion: https://www.postgresql.org/message-id/CB7A53AA-5645-4BDD-AB07-4D22CD9D8FF1%40gmx.net Author: Tobias Bussmann Branch -- master Details

[COMMITTERS] pgsql: Fix function comment for dumpACL()

Fix function comment for dumpACL() The comment for dumpACL() got neglected when initacls and initracls were added and the discussion of what 'racls' is wasn't very clear either. Per complaint from Tom. Branch -- master Details ---

[COMMITTERS] pgsql: Fix function comment for dumpACL()

Fix function comment for dumpACL() The comment for dumpACL() got neglected when initacls and initracls were added and the discussion of what 'racls' is wasn't very clear either. Per complaint from Tom. Branch -- REL9_6_STABLE Details ---

[COMMITTERS] pgsql: Do not require 'public' to exist for pg_dump -c

Do not require 'public' to exist for pg_dump -c Commit 330b84d8c4 didn't contemplate the case where the public schema has been dropped and introduced a query which fails when there is no public schema into pg_dump (when used with -c). Adjust the query used by pg_dump to handle the case where the

[COMMITTERS] pgsql: Do not require 'public' to exist for pg_dump -c

Do not require 'public' to exist for pg_dump -c Commit 330b84d8c4 didn't contemplate the case where the public schema has been dropped and introduced a query which fails when there is no public schema into pg_dump (when used with -c). Adjust the query used by pg_dump to handle the case where the

[COMMITTERS] pgsql: pg_dump: Don't leak memory in buildDefaultACLCommands()

pg_dump: Don't leak memory in buildDefaultACLCommands() buildDefaultACLCommands() didn't destroy the string buffer created in certain cases, leading to a memory leak. Fix by destroying the buffer before returning from the function. Spotted by Coverity. Author: Michael Paquier Back-patch to

[COMMITTERS] pgsql: pg_dump: Don't leak memory in buildDefaultACLCommands()

pg_dump: Don't leak memory in buildDefaultACLCommands() buildDefaultACLCommands() didn't destroy the string buffer created in certain cases, leading to a memory leak. Fix by destroying the buffer before returning from the function. Spotted by Coverity. Author: Michael Paquier Back-patch to

[COMMITTERS] pgsql: RLS: Fix ALL vs. SELECT+UPDATE policy usage

RLS: Fix ALL vs. SELECT+UPDATE policy usage When we add the SELECT-privilege based policies to the RLS with check options (such as for an UPDATE statement, or when we have INSERT ... RETURNING), we need to be sure and use the 'USING' case if the policy is actually an 'ALL' policy (which could

[COMMITTERS] pgsql: RLS: Fix ALL vs. SELECT+UPDATE policy usage

RLS: Fix ALL vs. SELECT+UPDATE policy usage When we add the SELECT-privilege based policies to the RLS with check options (such as for an UPDATE statement, or when we have INSERT ... RETURNING), we need to be sure and use the 'USING' case if the policy is actually an 'ALL' policy (which could

[COMMITTERS] pgsql: RLS: Fix ALL vs. SELECT+UPDATE policy usage

RLS: Fix ALL vs. SELECT+UPDATE policy usage When we add the SELECT-privilege based policies to the RLS with check options (such as for an UPDATE statement, or when we have INSERT ... RETURNING), we need to be sure and use the 'USING' case if the policy is actually an 'ALL' policy (which could

[COMMITTERS] pgsql: Change the way pg_dump retrieves partitioning info

Change the way pg_dump retrieves partitioning info This gets rid of the code that issued separate queries to retrieve the partitioning parent-child relationship, parent partition key, and child partition bound information. With this patch, the information is retrieved instead using the queries

[COMMITTERS] pgsql: Remove unnecessairly duplicated gram.y productions

Remove unnecessairly duplicated gram.y productions Declarative partitioning duplicated the TypedTableElement productions, evidently to remove the need to specify WITH OPTIONS when creating partitions. Instead, simply make WITH OPTIONS optional in the TypedTableElement production and remove all

[COMMITTERS] pgsql: Remove --verbose from PROVE_FLAGS

Remove --verbose from PROVE_FLAGS Per discussion, the TAP tests are really more verbose than necessary, so remove the --verbose flag from PROVE_FLAGS. Also add comments to let folks know how they can enable it if they really wish to, as suggested by Craig Ringer. Author: Michael Paquier,

Re: [COMMITTERS] pgsql: Add COMMENT and SECURITY LABEL support for publications and subs

Peter, * Peter Eisentraut (pete...@gmx.net) wrote: > Add COMMENT and SECURITY LABEL support for publications and subscriptions Isn't this missing psql tab completion, and pg_dump support? And regression tests for the latter? Thanks! Stephen signature.asc Description: Digital signature

Re: [COMMITTERS] pgsql: Logical replication support for initial data copy

Petr, * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote: > On 23/03/17 14:47, Petr Jelinek wrote: > > I am looking into buildfarm failures. > > > > Looks like the clang issue (mylodon, longfin) is because we are missing > > extern in include/replication/worker_internal.h for ApplyCacheContext.

[COMMITTERS] pgsql: Expose waitforarchive option through pg_stop_backup()

Expose waitforarchive option through pg_stop_backup() Internally, we have supported the option to either wait for all of the WAL associated with a backup to be archived, or to return immediately. This option is useful to users of pg_stop_backup() as well, when they are reading the stop backup

[COMMITTERS] pgsql: pg_dump: Skip COLLATION-related regression tests

pg_dump: Skip COLLATION-related regression tests Not every platform supports non-default collations, as pointed out by the buildfarm, so skip collation-related regression tests in pg_dump when they aren't supported. Branch -- master Details ---

[COMMITTERS] pgsql: Adjust number of tests for pg_dump 001_basic.pl

Adjust number of tests for pg_dump 001_basic.pl When removing a test, need to make sure the count of tests is adjusted when it isn't calculated. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/805e8bc7029b6eb19f0ca3a68051cfda5bd07ef3 Modified Files --

[COMMITTERS] pgsql: pg_dump: Remove "option requires an argument -- j" test

pg_dump: Remove "option requires an argument -- j" test This is really testing getopt more than pg_dump, and what getopt returns exactly appears to differ based on platform, so remove this test. Per buildfarm. Branch -- master Details ---

[COMMITTERS] pgsql: Improve pg_dump regression tests and code coverage

Improve pg_dump regression tests and code coverage These improvements bring the lines-of-code coverage of pg_dump.c up to 87.7% (at least using LCOV 1.12, 1.11 seems to differ slightly). Nearly every function is covered, three of the four which aren't are only called when talking to older PG

[COMMITTERS] pgsql: Be more careful about signed vs. unsigned char

Be more careful about signed vs. unsigned char The buildfarm has reminded me that not all systems consider char to be signed and we need to be explicit. Adjust the various bits of mac8.c for what we intend, mostly using casts to unsigned char as suggested by Tom, and adjust the tests for valid

Re: [COMMITTERS] pgsql: Clean up overly paranoid checks in mac8.c

* Tom Lane (t...@sss.pgh.pa.us) wrote: > I wrote: > > Stephen Frost <sfr...@snowman.net> writes: > >> Clean up overly paranoid checks in mac8.c > > > termite thinks this wasn't quite right. > > On looking at it a bit more closely, I think you've fo

Re: [COMMITTERS] pgsql: Clean up overly paranoid checks in mac8.c

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > Clean up overly paranoid checks in mac8.c > > termite thinks this wasn't quite right. Seems to be that termite's char is unsigned, will be fixing in a moment. Thanks! Stephen sign

[COMMITTERS] pgsql: Clean up overly paranoid checks in mac8.c

Clean up overly paranoid checks in mac8.c Andres' compiler points out, quite correctly, that there's no need for some of the overly paranoid checks which were put into mac8.c. Remove those, as they're useless, add some comments and make a few other minor improvements- reduce the size of

[COMMITTERS] pgsql: Bump catversion for MACADDR8

Bump catversion for MACADDR8 Pointed out by Robert. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/c5832346625af4193b1242e57e7d13e66a220b38 Modified Files -- src/include/catalog/catversion.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --

[COMMITTERS] pgsql: Add support for EUI-64 MAC addresses as macaddr8

Add support for EUI-64 MAC addresses as macaddr8 This adds in support for EUI-64 MAC addresses by adding a new data type called 'macaddr8' (using our usual convention of indicating the number of bytes stored). This was largely a copy-and-paste from the macaddr data type, with appropriate

[COMMITTERS] pgsql: pgstattuple: Fix typo partitiond -> partitioned

pgstattuple: Fix typo partitiond -> partitioned Pointed out by Michael Paquier Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/90e91e242fe99582b6d2dc18177e79d99c91695d Modified Files -- contrib/pgstattuple/expected/pgstattuple.out | 2 +-

[COMMITTERS] pgsql: Add relkind checks to certain contrib modules

Add relkind checks to certain contrib modules The contrib extensions pageinspect, pg_visibility and pgstattuple only work against regular relations which have storage. They don't work against foreign tables, partitioned (parent) tables, views, et al. Add checks to the user-callable functions to

[COMMITTERS] pgsql: Expose explain's SUMMARY option

Expose explain's SUMMARY option This exposes the existing explain summary option to users to allow them to choose if they wish to have the planning time and totalled run time included in the EXPLAIN result. The existing default behavior is retained if SUMMARY is not specified- running explain

[COMMITTERS] pgsql: psql: Add \gx command

psql: Add \gx command It can often be useful to use expanded mode output (\x) for just a single query. Introduce a \gx which acts exactly like \g except that it will force expanded output mode for that one \gx call. This is simpler than having to use \x as a toggle and also means that the user

[COMMITTERS] pgsql: pg_dump: Properly handle public schema ACLs with --clean

pg_dump: Properly handle public schema ACLs with --clean pg_dump has always handled the public schema in a special way when it comes to the "--clean" option. To wit, we do not drop or recreate the public schema in "normal" mode, but when we are run in "--clean" mode then we do drop and recreate

[COMMITTERS] pgsql: pg_dump: Properly handle public schema ACLs with --clean

pg_dump: Properly handle public schema ACLs with --clean pg_dump has always handled the public schema in a special way when it comes to the "--clean" option. To wit, we do not drop or recreate the public schema in "normal" mode, but when we are run in "--clean" mode then we do drop and recreate

[COMMITTERS] pgsql: pg_upgrade: Fix large object COMMENTS, SECURITY LABELS

pg_upgrade: Fix large object COMMENTS, SECURITY LABELS When performing a pg_upgrade, we copy the files behind pg_largeobject and pg_largeobject_metadata, allowing us to avoid having to dump out and reload the actual data for large objects and their ACLs. Unfortunately, that isn't all of the

[COMMITTERS] pgsql: pg_upgrade: Fix large object COMMENTS, SECURITY LABELS

pg_upgrade: Fix large object COMMENTS, SECURITY LABELS When performing a pg_upgrade, we copy the files behind pg_largeobject and pg_largeobject_metadata, allowing us to avoid having to dump out and reload the actual data for large objects and their ACLs. Unfortunately, that isn't all of the

[COMMITTERS] pgsql: pg_upgrade: Fix large object COMMENTS, SECURITY LABELS

pg_upgrade: Fix large object COMMENTS, SECURITY LABELS When performing a pg_upgrade, we copy the files behind pg_largeobject and pg_largeobject_metadata, allowing us to avoid having to dump out and reload the actual data for large objects and their ACLs. Unfortunately, that isn't all of the

[COMMITTERS] pgsql: pg_upgrade: Fix large object COMMENTS, SECURITY LABELS

pg_upgrade: Fix large object COMMENTS, SECURITY LABELS When performing a pg_upgrade, we copy the files behind pg_largeobject and pg_largeobject_metadata, allowing us to avoid having to dump out and reload the actual data for large objects and their ACLs. Unfortunately, that isn't all of the

[COMMITTERS] pgsql: pg_upgrade: Fix large object COMMENTS, SECURITY LABELS

pg_upgrade: Fix large object COMMENTS, SECURITY LABELS When performing a pg_upgrade, we copy the files behind pg_largeobject and pg_largeobject_metadata, allowing us to avoid having to dump out and reload the actual data for large objects and their ACLs. Unfortunately, that isn't all of the

[COMMITTERS] pgsql: pg_upgrade: Fix large object COMMENTS, SECURITY LABELS

pg_upgrade: Fix large object COMMENTS, SECURITY LABELS When performing a pg_upgrade, we copy the files behind pg_largeobject and pg_largeobject_metadata, allowing us to avoid having to dump out and reload the actual data for large objects and their ACLs. Unfortunately, that isn't all of the

Re: [COMMITTERS] pgsql: Mark pg_start_backup and pg_stop_backup as parallel-restricted.

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > David Steele writes: > > On 3/6/17 12:48 PM, Robert Haas wrote: > >> This issue also exists in 9.6, but we obviously can't do anything > >> about 9.6 clusters that already exist. Possibly this could be > >> back-patched so that

[COMMITTERS] pgsql: Initialize number_of_jobs in NewRestoreOptions

Initialize number_of_jobs in NewRestoreOptions Now that we're checking that the number_of_jobs passed in isn't zero or negative, we need to actually initialize number_of_jobs to '1' when it isn't set. Pointed out by Rushabh Lathia, though not his patch. Discussion:

[COMMITTERS] pgsql: pg_dump: Fix handling of ALTER DEFAULT PRIVILEGES

pg_dump: Fix handling of ALTER DEFAULT PRIVILEGES In commit 23f34fa, we changed how ACLs were handled to use the new pg_init_privs catalog and to dump out the ACL commands as REVOKE+GRANT combinations instead of trying to REVOKE all rights always and then GRANT back just the ones which were in

[COMMITTERS] pgsql: pg_dump: Fix handling of ALTER DEFAULT PRIVILEGES

pg_dump: Fix handling of ALTER DEFAULT PRIVILEGES In commit 23f34fa, we changed how ACLs were handled to use the new pg_init_privs catalog and to dump out the ACL commands as REVOKE+GRANT combinations instead of trying to REVOKE all rights always and then GRANT back just the ones which were in

[COMMITTERS] pgsql: perltidy pg_dump TAP tests

perltidy pg_dump TAP tests The pg_dump TAP tests have gotten pretty far from what perltidy thinks they should be, so fix that, and in passing use long-form argument names with arguments passed via "=" in a similar vein to 58da833. No functional changes here, just whitespace and changing runs

[COMMITTERS] pgsql: test_pg_dump: perltidy cleanup

test_pg_dump: perltidy cleanup As pointed out by Alvaro, we actually use perltidy on the perl scripts in the source tree, so go back to the results of a perltidy run for the test_pg_dump TAP script. To make it look slightly less tragic, I changed most of the independent arguments into long-form

[COMMITTERS] pgsql: test_pg_dump: perltidy cleanup

test_pg_dump: perltidy cleanup As pointed out by Alvaro, we actually use perltidy on the perl scripts in the source tree, so go back to the results of a perltidy run for the test_pg_dump TAP script. To make it look slightly less tragic, I changed most of the independent arguments into long-form

Re: [COMMITTERS] pgsql: test_pg_dump TAP test whitespace cleanup

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > test_pg_dump TAP test whitespace cleanup > > > > The formatting of the perl hashes used in the TAP tests for test_pg_dump > > was rather horribly inconsistent and made it more difficult tha

[COMMITTERS] pgsql: Handle ALTER EXTENSION ADD/DROP with pg_init_privs

Handle ALTER EXTENSION ADD/DROP with pg_init_privs In commit 6c268df, pg_init_privs was added to track the initial privileges of catalog objects and extensions. Unfortunately, that commit didn't include understanding of ALTER EXTENSION ADD/DROP, which allows the objects associated with an

[COMMITTERS] pgsql: Handle ALTER EXTENSION ADD/DROP with pg_init_privs

Handle ALTER EXTENSION ADD/DROP with pg_init_privs In commit 6c268df, pg_init_privs was added to track the initial privileges of catalog objects and extensions. Unfortunately, that commit didn't include understanding of ALTER EXTENSION ADD/DROP, which allows the objects associated with an

[COMMITTERS] pgsql: test_pg_dump TAP test whitespace cleanup

test_pg_dump TAP test whitespace cleanup The formatting of the perl hashes used in the TAP tests for test_pg_dump was rather horribly inconsistent and made it more difficult than it really should have been to add new tests or adjust what tests are for what runs, etc. Reformat to clean that all

[COMMITTERS] pgsql: test_pg_dump TAP test whitespace cleanup

test_pg_dump TAP test whitespace cleanup The formatting of the perl hashes used in the TAP tests for test_pg_dump was rather horribly inconsistent and made it more difficult than it really should have been to add new tests or adjust what tests are for what runs, etc. Reformat to clean that all

Re: [COMMITTERS] pgsql: Logical replication

* Peter Eisentraut (pete...@gmx.net) wrote: > Logical replication > > - Add PUBLICATION catalogs and DDL > - Add SUBSCRIPTION catalog and DDL > - Define logical replication protocol and output plugin > - Add logical replication workers The buildfarm is rather upset with this. Looks like an

[COMMITTERS] pgsql: Dump sequence data based on the TableDataInfo flag

Dump sequence data based on the TableDataInfo flag When considering a sequence's Data entry in dumpSequenceData, we were actually looking at the sequence definition's dump flag to decide if we should dump the data or not. That's generally fine, except for when the sequence data entry was created

[COMMITTERS] pgsql: Dump sequence data based on the TableDataInfo flag

Dump sequence data based on the TableDataInfo flag When considering a sequence's Data entry in dumpSequenceData, we were actually looking at the sequence definition's dump flag to decide if we should dump the data or not. That's generally fine, except for when the sequence data entry was created

Re: [COMMITTERS] pgsql: Add function to import operating system collations

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> WFM. Btw, I noticed that BOOTSTRAP_SUPERUSERID is hard-coded as "10" > >> in this bit in setup_privileges(): > &g

Re: [COMMITTERS] pgsql: Add function to import operating system collations

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Peter Eisentraut writes: > > On 1/19/17 7:53 AM, Tom Lane wrote: > >> Hm. I see that the patch randomly changed the way that the collation > >> owner is generated ... looks like it no longer works for mixed-case > >>

[COMMITTERS] pgsql: pg_restore: Don't allow non-positive number of jobs

pg_restore: Don't allow non-positive number of jobs pg_restore will currently accept invalid values for the number of parallel jobs to run (eg: -1), unlike pg_dump which does check that the value provided is reasonable. Worse, '-1' is actually a valid, independent, parameter (as an alias for

[COMMITTERS] pgsql: pg_restore: Don't allow non-positive number of jobs

pg_restore: Don't allow non-positive number of jobs pg_restore will currently accept invalid values for the number of parallel jobs to run (eg: -1), unlike pg_dump which does check that the value provided is reasonable. Worse, '-1' is actually a valid, independent, parameter (as an alias for

[COMMITTERS] pgsql: pg_restore: Don't allow non-positive number of jobs

pg_restore: Don't allow non-positive number of jobs pg_restore will currently accept invalid values for the number of parallel jobs to run (eg: -1), unlike pg_dump which does check that the value provided is reasonable. Worse, '-1' is actually a valid, independent, parameter (as an alias for

[COMMITTERS] pgsql: pg_restore: Don't allow non-positive number of jobs

pg_restore: Don't allow non-positive number of jobs pg_restore will currently accept invalid values for the number of parallel jobs to run (eg: -1), unlike pg_dump which does check that the value provided is reasonable. Worse, '-1' is actually a valid, independent, parameter (as an alias for

[COMMITTERS] pgsql: pg_restore: Don't allow non-positive number of jobs

pg_restore: Don't allow non-positive number of jobs pg_restore will currently accept invalid values for the number of parallel jobs to run (eg: -1), unlike pg_dump which does check that the value provided is reasonable. Worse, '-1' is actually a valid, independent, parameter (as an alias for

[COMMITTERS] pgsql: pg_restore: Don't allow non-positive number of jobs

pg_restore: Don't allow non-positive number of jobs pg_restore will currently accept invalid values for the number of parallel jobs to run (eg: -1), unlike pg_dump which does check that the value provided is reasonable. Worse, '-1' is actually a valid, independent, parameter (as an alias for

[COMMITTERS] pgsql: pg_dump: Strict names with no matching schema

pg_dump: Strict names with no matching schema When using pg_dump --strict-names and a schema pattern which doesn't match any schemas (eg: --schema='nonexistant*'), we were incorrectly throwing an error claiming no tables were found when, really, there were no schemas found: -> pg_dump

[COMMITTERS] pgsql: pg_dump: Strict names with no matching schema

pg_dump: Strict names with no matching schema When using pg_dump --strict-names and a schema pattern which doesn't match any schemas (eg: --schema='nonexistant*'), we were incorrectly throwing an error claiming no tables were found when, really, there were no schemas found: -> pg_dump

[COMMITTERS] pgsql: Fix invalid-parallel-jobs error message

Fix invalid-parallel-jobs error message Including the program name twice is not helpful: -> pg_dump -j -1 pg_dump: pg_dump: invalid number of parallel jobs Correct by removing the progname from the exit_horribly() call used when validating the number of parallel jobs. Noticed while testing

[COMMITTERS] pgsql: Fix invalid-parallel-jobs error message

Fix invalid-parallel-jobs error message Including the program name twice is not helpful: -> pg_dump -j -1 pg_dump: pg_dump: invalid number of parallel jobs Correct by removing the progname from the exit_horribly() call used when validating the number of parallel jobs. Noticed while testing

[COMMITTERS] pgsql: Fix invalid-parallel-jobs error message

Fix invalid-parallel-jobs error message Including the program name twice is not helpful: -> pg_dump -j -1 pg_dump: pg_dump: invalid number of parallel jobs Correct by removing the progname from the exit_horribly() call used when validating the number of parallel jobs. Noticed while testing

[COMMITTERS] pgsql: Fix invalid-parallel-jobs error message

Fix invalid-parallel-jobs error message Including the program name twice is not helpful: -> pg_dump -j -1 pg_dump: pg_dump: invalid number of parallel jobs Correct by removing the progname from the exit_horribly() call used when validating the number of parallel jobs. Noticed while testing

[COMMITTERS] pgsql: Fix invalid-parallel-jobs error message

Fix invalid-parallel-jobs error message Including the program name twice is not helpful: -> pg_dump -j -1 pg_dump: pg_dump: invalid number of parallel jobs Correct by removing the progname from the exit_horribly() call used when validating the number of parallel jobs. Noticed while testing

[COMMITTERS] pgsql: Add basic pg_dumpall/pg_restore TAP tests

Add basic pg_dumpall/pg_restore TAP tests For reasons unknown, pg_dumpall and pg_restore managed to escape the basic set of TAP tests that were added for pg_dump in 6bd356c3, so let's get them added now. A few minor adjustments are also made to the dump/restore tests to improve code coverage for

[COMMITTERS] pgsql: Protect against NULL-dereference in pg_dump

Protect against NULL-dereference in pg_dump findTableByOid() is allowed to return NULL and we should therefore be checking for that case. getOwnedSeqs() and dumpSequence() shouldn't ever actually see this happen, but given odd circumstances it might and commit f9e439b1 probably shouldn't have

[COMMITTERS] pgsql: Protect against NULL-dereference in pg_dump

Protect against NULL-dereference in pg_dump findTableByOid() is allowed to return NULL and we should therefore be checking for that case. getOwnedSeqs() and dumpSequence() shouldn't ever actually see this happen, but given odd circumstances it might and commit f9e439b1 probably shouldn't have

Re: [COMMITTERS] pgsql: Update copyright for 2017

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Andres Freund writes: > > On 2017-01-03 13:02:28 -0500, Bruce Momjian wrote: > >> Yeah, I was doing parallel pulls of different branches in git via shell > >> script, and it seems the size of this commit showed me that doesn't > >>

[COMMITTERS] pgsql: pg_dumpall: Include --verbose option in --help output

pg_dumpall: Include --verbose option in --help output The -v/--verbose option was not included in the output from --help for pg_dumpall even though it's in the pg_dumpall documentation and has apparently been around since pg_dumpall was reimplemented in C in 2002. Fix that by adding it. Pointed

[COMMITTERS] pgsql: pg_dumpall: Include --verbose option in --help output

pg_dumpall: Include --verbose option in --help output The -v/--verbose option was not included in the output from --help for pg_dumpall even though it's in the pg_dumpall documentation and has apparently been around since pg_dumpall was reimplemented in C in 2002. Fix that by adding it. Pointed

[COMMITTERS] pgsql: pg_dumpall: Include --verbose option in --help output

pg_dumpall: Include --verbose option in --help output The -v/--verbose option was not included in the output from --help for pg_dumpall even though it's in the pg_dumpall documentation and has apparently been around since pg_dumpall was reimplemented in C in 2002. Fix that by adding it. Pointed

[COMMITTERS] pgsql: pg_dumpall: Include --verbose option in --help output

pg_dumpall: Include --verbose option in --help output The -v/--verbose option was not included in the output from --help for pg_dumpall even though it's in the pg_dumpall documentation and has apparently been around since pg_dumpall was reimplemented in C in 2002. Fix that by adding it. Pointed

[COMMITTERS] pgsql: pg_dumpall: Include --verbose option in --help output

pg_dumpall: Include --verbose option in --help output The -v/--verbose option was not included in the output from --help for pg_dumpall even though it's in the pg_dumpall documentation and has apparently been around since pg_dumpall was reimplemented in C in 2002. Fix that by adding it. Pointed

[COMMITTERS] pgsql: pg_dumpall: Include --verbose option in --help output

pg_dumpall: Include --verbose option in --help output The -v/--verbose option was not included in the output from --help for pg_dumpall even though it's in the pg_dumpall documentation and has apparently been around since pg_dumpall was reimplemented in C in 2002. Fix that by adding it. Pointed

Re: [COMMITTERS] pgsql: Fix tab completion in psql for ALTER DEFAULT PRIVILEGES

* Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Dec 23, 2016 at 9:02 PM, Stephen Frost <sfr...@snowman.net> wrote: > > Lastly, we weren't using the actual list of allowed kinds of > > objects for default privileges for completion after the 'GRANT X ON' but > &g

[COMMITTERS] pgsql: Fix tab completion in psql for ALTER DEFAULT PRIVILEGES

Fix tab completion in psql for ALTER DEFAULT PRIVILEGES When providing tab completion for ALTER DEFAULT PRIVILEGES, we are including the list of roles as possible options for completion after the GRANT or REVOKE. Further, we accept FOR ROLE/IN SCHEMA at the same time and in either order, but the

[COMMITTERS] pgsql: Fix tab completion in psql for ALTER DEFAULT PRIVILEGES

Fix tab completion in psql for ALTER DEFAULT PRIVILEGES When providing tab completion for ALTER DEFAULT PRIVILEGES, we are including the list of roles as possible options for completion after the GRANT or REVOKE. Further, we accept FOR ROLE/IN SCHEMA at the same time and in either order, but the

[COMMITTERS] pgsql: Fix tab completion in psql for ALTER DEFAULT PRIVILEGES

Fix tab completion in psql for ALTER DEFAULT PRIVILEGES When providing tab completion for ALTER DEFAULT PRIVILEGES, we are including the list of roles as possible options for completion after the GRANT or REVOKE. Further, we accept FOR ROLE/IN SCHEMA at the same time and in either order, but the

[COMMITTERS] pgsql: Fix tab completion in psql for ALTER DEFAULT PRIVILEGES

Fix tab completion in psql for ALTER DEFAULT PRIVILEGES When providing tab completion for ALTER DEFAULT PRIVILEGES, we are including the list of roles as possible options for completion after the GRANT or REVOKE. Further, we accept FOR ROLE/IN SCHEMA at the same time and in either order, but the

[COMMITTERS] pgsql: Fix tab completion in psql for ALTER DEFAULT PRIVILEGES

Fix tab completion in psql for ALTER DEFAULT PRIVILEGES When providing tab completion for ALTER DEFAULT PRIVILEGES, we are including the list of roles as possible options for completion after the GRANT or REVOKE. Further, we accept FOR ROLE/IN SCHEMA at the same time and in either order, but the

[COMMITTERS] pgsql: Fix tab completion in psql for ALTER DEFAULT PRIVILEGES

Fix tab completion in psql for ALTER DEFAULT PRIVILEGES When providing tab completion for ALTER DEFAULT PRIVILEGES, we are including the list of roles as possible options for completion after the GRANT or REVOKE. Further, we accept FOR ROLE/IN SCHEMA at the same time and in either order, but the

[COMMITTERS] pgsql: Use TSConfigRelationId in AlterTSConfiguration()

Use TSConfigRelationId in AlterTSConfiguration() When we are altering a text search configuration, we are getting the tuple from pg_ts_config and using its OID, so use TSConfigRelationId when invoking any post-alter hooks and setting the object address. Further, in the functions called from

[COMMITTERS] pgsql: Use TSConfigRelationId in AlterTSConfiguration()

Use TSConfigRelationId in AlterTSConfiguration() When we are altering a text search configuration, we are getting the tuple from pg_ts_config and using its OID, so use TSConfigRelationId when invoking any post-alter hooks and setting the object address. Further, in the functions called from

[COMMITTERS] pgsql: Use TSConfigRelationId in AlterTSConfiguration()

Use TSConfigRelationId in AlterTSConfiguration() When we are altering a text search configuration, we are getting the tuple from pg_ts_config and using its OID, so use TSConfigRelationId when invoking any post-alter hooks and setting the object address. Further, in the functions called from

[COMMITTERS] pgsql: Use TSConfigRelationId in AlterTSConfiguration()

Use TSConfigRelationId in AlterTSConfiguration() When we are altering a text search configuration, we are getting the tuple from pg_ts_config and using its OID, so use TSConfigRelationId when invoking any post-alter hooks and setting the object address. Further, in the functions called from

[COMMITTERS] pgsql: Use TSConfigRelationId in AlterTSConfiguration()

Use TSConfigRelationId in AlterTSConfiguration() When we are altering a text search configuration, we are getting the tuple from pg_ts_config and using its OID, so use TSConfigRelationId when invoking any post-alter hooks and setting the object address. Further, in the functions called from

[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: 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: 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

  1   2   3   4   5   >