[COMMITTERS] Migration to pglister - Before

[Stephen Frost]

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 users can be found
on the wiki here: https://wiki.postgresql.org/wiki/PGLister_Announce

Once the migration of these lists is complete, an 'after' email will be
sent out.

Thanks!

Stephen


signature.asc
Description: Digital signature

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

[Stephen Frost]

* 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
Description: Digital signature

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

[Stephen Frost]

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 cases appear reasonable and
also mention the distinction between 'CREATE ROLE' and 'CREATE USER'.
Also, don't say CREATE USER "assumes" LOGIN, but rather "includes".

Patch-by: David G. Johnston, with assumes->includes by me.
Discussion: 
https://postgr.es/m/CAKFQuwYrbhKV8hH4TEABrDRBwf=gKremF=mlpq6x2ygqxgf...@mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/0fe2780db4876cb38f9f914c855a54db7c141e2f

Modified Files
--
doc/src/sgml/client-auth.sgml | 4 ++--
doc/src/sgml/ref/create_database.sgml | 2 +-
doc/src/sgml/user-manag.sgml  | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Fix ordering in pg_dump of GRANTs

[Stephen Frost]

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 only change
existing ACLs in-place, only add new ACLs to the end, and when removing
an ACL we remove any which depend on it also.

Also, adjust the comments in acl.h to make this clear.

Unfortunately, the updates to pg_dump to handle initial privileges
involved pulling apart ACLs and then combining them back together and
could end up putting them back together in an invalid order, leading to
dumps which wouldn't restore.

Fix this by adjusting the queries used by pg_dump to ensure that the
ACLs are rebuilt in the same order in which they were originally.

Back-patch to 9.6 where the changes for initial privileges were done.

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/d2e40b310aea1050fd499f62f391329f2c331f6a

Modified Files
--
src/bin/pg_dump/dumputils.c | 51 -
src/include/utils/acl.h | 14 ++---
2 files changed, 47 insertions(+), 18 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Fix ordering in pg_dump of GRANTs

[Stephen Frost]

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 only change
existing ACLs in-place, only add new ACLs to the end, and when removing
an ACL we remove any which depend on it also.

Also, adjust the comments in acl.h to make this clear.

Unfortunately, the updates to pg_dump to handle initial privileges
involved pulling apart ACLs and then combining them back together and
could end up putting them back together in an invalid order, leading to
dumps which wouldn't restore.

Fix this by adjusting the queries used by pg_dump to ensure that the
ACLs are rebuilt in the same order in which they were originally.

Back-patch to 9.6 where the changes for initial privileges were done.

Branch
--
REL_10_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/68a7c24fdf2d69fc57cfb26aba7e119aa6ca2621

Modified Files
--
src/bin/pg_dump/dumputils.c | 51 -
src/include/utils/acl.h | 14 ++---
2 files changed, 47 insertions(+), 18 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Fix ordering in pg_dump of GRANTs

[Stephen Frost]

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 only change
existing ACLs in-place, only add new ACLs to the end, and when removing
an ACL we remove any which depend on it also.

Also, adjust the comments in acl.h to make this clear.

Unfortunately, the updates to pg_dump to handle initial privileges
involved pulling apart ACLs and then combining them back together and
could end up putting them back together in an invalid order, leading to
dumps which wouldn't restore.

Fix this by adjusting the queries used by pg_dump to ensure that the
ACLs are rebuilt in the same order in which they were originally.

Back-patch to 9.6 where the changes for initial privileges were done.

Branch
--
REL9_6_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/caae416aac83db7c96695c1927a254e82f7da5dc

Modified Files
--
src/bin/pg_dump/dumputils.c | 51 -
src/include/utils/acl.h | 14 ++---
2 files changed, 47 insertions(+), 18 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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

Details
---
https://git.postgresql.org/pg/commitdiff/51d0fa8ed93fe5befe91498f1a3eb5aede32677a

Modified Files
--
src/bin/psql/common.c  |  4 
src/test/regress/expected/psql.out | 25 +
src/test/regress/sql/psql.sql  | 10 ++
3 files changed, 39 insertions(+)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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
---
https://git.postgresql.org/pg/commitdiff/0cdc3e47bea442643c9870dc419364b9f2f52dcb

Modified Files
--
src/bin/psql/common.c  |  4 
src/test/regress/expected/psql.out | 25 +
src/test/regress/sql/psql.sql  | 10 ++
3 files changed, 39 insertions(+)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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
---
https://git.postgresql.org/pg/commitdiff/d2a51e3efcbab5b288bbadba1a7dfa123a50ba5b

Modified Files
--
src/bin/pg_dump/pg_dump.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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
---
https://git.postgresql.org/pg/commitdiff/d38e706ff149eb0937502cc0be27645e70bbfec6

Modified Files
--
src/bin/pg_dump/pg_dump.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 public
schema doesn't exist and add tests to check that such a case no longer
fails.

Back-patch the specific fix to 9.6, as the prior commit was.

Adding tests for this case involved adding support to the pg_dump
TAP tests to work with multiple databases, which, while not a large
change, is a bit much to back-patch, so that's only done in master.

Addresses bug #14650
Discussion: 
https://www.postgresql.org/message-id/20170512181801.1795.47483%40wrigleys.postgresql.org

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/4500edc7e9cf771bf8960d1f3f620917871bdb6f

Modified Files
--
src/bin/pg_dump/pg_dump.c|   7 ++-
src/bin/pg_dump/t/002_pg_dump.pl | 110 +--
2 files changed, 113 insertions(+), 4 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 public
schema doesn't exist and add tests to check that such a case no longer
fails.

Back-patch the specific fix to 9.6, as the prior commit was.

Adding tests for this case involved adding support to the pg_dump
TAP tests to work with multiple databases, which, while not a large
change, is a bit much to back-patch, so that's only done in master.

Addresses bug #14650
Discussion: 
https://www.postgresql.org/message-id/20170512181801.1795.47483%40wrigleys.postgresql.org

Branch
--
REL9_6_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/a2de017b30157c99e33cbc6457140e062a5ca26f

Modified Files
--
src/bin/pg_dump/pg_dump.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 9.6 where buildDefaultACLCommands() was added.

Branch
--
REL9_6_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/ef42c1103708cbbb77fff674f339d452a13aac14

Modified Files
--
src/bin/pg_dump/dumputils.c | 6 ++
1 file changed, 6 insertions(+)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 9.6 where buildDefaultACLCommands() was added.

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/09f842181943b6e83b0779f2e872ff0180b66883

Modified Files
--
src/bin/pg_dump/dumputils.c | 6 ++
1 file changed, 6 insertions(+)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 have both a USING clause and an
independent WITH CHECK clause).

This could result in policies acting differently when built using ALL
(when the ALL had both USING and WITH CHECK clauses) and when building
the policies independently as SELECT and UPDATE policies.

Fix this by adding an explicit boolean to add_with_check_options() to
indicate when the USING policy should be used, even if the policy has
both USING and WITH CHECK policies on it.

Reported by: Rod Taylor

Back-patch to 9.5 where RLS was introduced.

Branch
--
REL9_6_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/92b15224b4eac8eeae0616491ccf0c852fa2dff9

Modified Files
--
src/backend/rewrite/rowsecurity.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 have both a USING clause and an
independent WITH CHECK clause).

This could result in policies acting differently when built using ALL
(when the ALL had both USING and WITH CHECK clauses) and when building
the policies independently as SELECT and UPDATE policies.

Fix this by adding an explicit boolean to add_with_check_options() to
indicate when the USING policy should be used, even if the policy has
both USING and WITH CHECK policies on it.

Reported by: Rod Taylor

Back-patch to 9.5 where RLS was introduced.

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/aa5d3c0b3fb906dfa910b0ca6f75ab701b2f1c09

Modified Files
--
src/backend/rewrite/rowsecurity.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 have both a USING clause and an
independent WITH CHECK clause).

This could result in policies acting differently when built using ALL
(when the ALL had both USING and WITH CHECK clauses) and when building
the policies independently as SELECT and UPDATE policies.

Fix this by adding an explicit boolean to add_with_check_options() to
indicate when the USING policy should be used, even if the policy has
both USING and WITH CHECK policies on it.

Reported by: Rod Taylor

Back-patch to 9.5 where RLS was introduced.

Branch
--
REL9_5_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/d617c7629c0806a24c0fe74331935c726569

Modified Files
--
src/backend/rewrite/rowsecurity.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 issued from getTables() and
getInherits(), which is both more efficient than the previous approach
and doesn't require any new code.

Since the partitioning parent-child relationship is now retrieved with
the same old code that handles inheritance, partition attributes receive
a proper flagInhAttrs() treatment (that it didn't receive before), which
is needed so that the inherited NOT NULL constraints are not emitted if
we already emitted it for the parent.

Also, fix a bug in pg_dump's --binary-upgrade code, which caused pg_dump
to emit invalid command to attach a partition to its parent.

Author: Amit Langote, with some additional changes by me.

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/44c528810a1eca52a7888ed74c08353d45331b00

Modified Files
--
src/bin/pg_dump/common.c |  90 -
src/bin/pg_dump/pg_dump.c| 264 +--
src/bin/pg_dump/pg_dump.h|  15 +--
src/bin/pg_dump/t/002_pg_dump.pl |  36 +-
4 files changed, 153 insertions(+), 252 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 of the duplicate
PartitionElement-related productions.  This change simplifies the
syntax and makes WITH OPTIONS optional when adding defaults, constraints
or storage parameters to columns when creating either typed tables or
partitions.

Also update pg_dump to no longer include WITH OPTIONS, since it's not
necessary, and update the documentation to reflect that WITH OPTIONS is
now optional.

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/b9a3ef55b253d885081c2d0e9dc45802cab71c7b

Modified Files
--
doc/src/sgml/ref/create_foreign_table.sgml |  2 +-
doc/src/sgml/ref/create_table.sgml |  4 +-
src/backend/parser/gram.y  | 68 ++
src/bin/pg_dump/pg_dump.c  | 17 +---
src/test/regress/expected/create_table.out |  2 +-
src/test/regress/expected/sanity_check.out |  3 ++
src/test/regress/expected/typed_table.out  | 37 ++--
src/test/regress/sql/create_table.sql  |  2 +-
src/test/regress/sql/typed_table.sql   | 21 -
9 files changed, 94 insertions(+), 62 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Remove --verbose from PROVE_FLAGS

[Stephen Frost]

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, additional comments by me.
Discussion: 
https://postgr.es/m/CAMsr%2BYGAzcMDOZ_BirnMCL6Sb%3DMUjP0FRE82YBDSbXcf6pm9Yg%40mail.gmail.com

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/e9c81b6016f431af808e4c08191e7aecf034dc80

Modified Files
--
src/Makefile.global.in | 3 ++-
src/test/perl/README   | 5 +
2 files changed, 7 insertions(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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

[Stephen Frost]

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.
> > 
> > Still analyzing the rest.
> 
> Ah missing fields in copy/equal function for AlterSubscriptionStmt.
> 
> Attached patch adds the above mentioned extern and fixes the copy and
> equal functions.

Pretty sure I saw a complaint about a trailing comma in a struct or enum
too..

Thanks!

Stephen


signature.asc
Description: Digital signature

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

[Stephen Frost]

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 record position and checking that the WAL
they need has been archived independently.

This patch adds an additional, optional, argument to pg_stop_backup()
which allows the user to indicate if they wish to wait for the WAL to be
archived or not.  The default matches current behavior, which is to
wait.

Author: David Steele, with some minor changes, doc updates by me.
Reviewed by: Takayuki Tsunakawa, Fujii Masao
Discussion: 
https://postgr.es/m/758e3fd1-45b4-5e28-75cd-e9e7f93a4...@pgmasters.net

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/017e4f2588a7fc6f2d1fbb6fff8afa1ff6e31f2b

Modified Files
--
doc/src/sgml/backup.sgml   | 13 -
doc/src/sgml/func.sgml | 10 --
src/backend/access/transam/xlog.c  |  3 ++-
src/backend/access/transam/xlogfuncs.c | 12 ++--
src/backend/catalog/system_views.sql   |  8 +++-
src/include/catalog/catversion.h   |  2 +-
src/include/catalog/pg_proc.h  |  2 +-
7 files changed, 41 insertions(+), 9 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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
---
http://git.postgresql.org/pg/commitdiff/de34123834c3fa465b97f65ded171888edbfbccf

Modified Files
--
src/bin/pg_dump/t/002_pg_dump.pl | 29 +
1 file changed, 29 insertions(+)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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
--
src/bin/pg_dump/t/001_basic.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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
---
http://git.postgresql.org/pg/commitdiff/5abda5a3e9e7f2a472ccbb1b8389d9166d4a9eca

Modified Files
--
src/bin/pg_dump/t/001_basic.pl | 5 -
1 file changed, 5 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 instances.

There is more which can, and should, be done here to improve the
coverage but it's past time to see what the buildfarm thinks of this.

What has been added:

- Coverage for many more command-line options
- Use command_fails_like instead of command_exit_is
- Operator classes, operator families
- Text search configuration, templates, parsers, dictionaries
- FDWs, servers, foreign tables
- Materialized views
- Improved Publications / Subscriptions test (though this needs work,
  see PG10 open items and tests marked with XXX in 002_pg_dump.pl)
- Unlogged tables
- Partitioned tables
- Additional ACL testing for various object types

There is room for improvement, specifically:

- Various type-based option (alignment, storage, etc)
- Composite type collation
- Extra Procedural language functions (inline, validator)
- Different function options (SRF, Transform, config, security definer,
  cost, leakproof)
- OpClass options (default, storage, order by, recheck)
- OpFamily options (order by, recheck)
- Aggregate functions (combinefunc, serialfunc, deserialfunc, etc)
- Text Search parser 'headline'
- Text Search template 'init'
- FDW options (handler, validator, options)
- Server options (type, version, options)
- User mapping options
- Default ACLs for sequences, types
- Security labels
- View circular dependencies (last function that needs coverage)
- Toast table autovacuum options
- Replica identity options
- Independent indexes (plus marking them as clustered on)
- Deferrable / initially deferred constraints
- Independent domain constraints

There's bits of extension pg_dump'ing also not covered, but those will
need to go into test_pg_dump (such as having a filter for config
tables).

Last, but not least, this approximately halves the number of tests run
with 'ok()' by removing the ok()-based checking of if all runs are
covered by each test.  Instead, 002_pg_dump.pl will just exit out in
such a case (with a message in the log file).  In general, when adding
tests, cover all runs unless there is a very good reason not to (such as
adding a 'catch-all' case).  With these changes, the resulting output
and number of "tests" run is actually reduced.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/31a8b77a9244a0883e1968adcff9b6038e575d77

Modified Files
--
src/bin/pg_dump/t/001_basic.pl   |  128 +-
src/bin/pg_dump/t/002_pg_dump.pl | 3773 --
2 files changed, 3340 insertions(+), 561 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 input accordingly.  Explicitly make
the hexlookup table signed as it's useful to use -1 there to indicate an
invalid value.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/cccbddeb1483b85f1853a29dc3b6464647b91eee

Modified Files
--
src/backend/utils/adt/mac8.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

* 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 forgotten that
> "char" is signed on some platforms and unsigned on others.  I'd
> suggest putting explicit casts to unsigned char into these tests.

Right, going through it now and adjusting things to be more careful
about that.

Thanks!

Stephen


signature.asc
Description: Digital signature

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

[Stephen Frost]

* 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


signature.asc
Description: Digital signature

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

[Stephen Frost]

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 hexlookup by making it a char array
instead of an int array, and pass in the ptr location directly instead
of making hex2_to_uchar re-calculate the location based off the offset
every time.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/7821f7229c6e149046ee0dd8cab57928c4f86a37

Modified Files
--
src/backend/utils/adt/mac8.c | 42 +-
1 file changed, 25 insertions(+), 17 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Bump catversion for MACADDR8

[Stephen Frost]

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(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 adjustments for having 8 bytes instead of 6 and adding
support for converting a provided EUI-48 (6 byte format) to the EUI-64
format.  Conversion from EUI-48 to EUI-64 inserts FFFE as the 4th and
5th bytes but does not perform the IPv6 modified EUI-64 action of
flipping the 7th bit, but we add a function to perform that specific
action for the user as it may be commonly done by users who wish to
calculate their IPv6 address based on their network prefix and 48-bit
MAC address.

Author: Haribabu Kommi, with a good bit of rework of macaddr8_in by me.
Reviewed by: Vitaly Burovoy, Kuntal Ghosh

Discussion: 
https://postgr.es/m/CAJrrPGcUi8ZH+KkK+=tctnq+efkecehtmu_yo1mvx8hsk_g...@mail.gmail.com

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/c7a9fa399d557c6366222e90b35db31e45d25678

Modified Files
--
contrib/btree_gin/Makefile  |   4 +-
contrib/btree_gin/btree_gin--1.0--1.1.sql   |  35 ++
contrib/btree_gin/btree_gin.c   |  10 +
contrib/btree_gin/btree_gin.control |   2 +-
contrib/btree_gin/expected/macaddr8.out |  51 +++
contrib/btree_gin/sql/macaddr8.sql  |  22 ++
contrib/btree_gist/Makefile |  11 +-
contrib/btree_gist/btree_gist--1.3--1.4.sql |  64 
contrib/btree_gist/btree_gist.control   |   2 +-
contrib/btree_gist/btree_gist.h |   1 +
contrib/btree_gist/btree_macaddr8.c | 200 ++
contrib/btree_gist/expected/macaddr8.out|  89 +
contrib/btree_gist/sql/macaddr8.sql |  37 ++
doc/src/sgml/brin.sgml  |  11 +
doc/src/sgml/btree-gin.sgml |   3 +-
doc/src/sgml/btree-gist.sgml|   4 +-
doc/src/sgml/datatype.sgml  |  83 +
doc/src/sgml/func.sgml  |  56 +++
src/backend/utils/adt/Makefile  |   2 +-
src/backend/utils/adt/mac.c |  13 +-
src/backend/utils/adt/mac8.c| 560 
src/backend/utils/adt/network.c |  10 +
src/backend/utils/adt/selfuncs.c|   1 +
src/include/catalog/pg_amop.h   |  18 +
src/include/catalog/pg_amproc.h |   7 +
src/include/catalog/pg_cast.h   |   6 +
src/include/catalog/pg_opclass.h|   3 +
src/include/catalog/pg_operator.h   |  23 +-
src/include/catalog/pg_opfamily.h   |   3 +
src/include/catalog/pg_proc.h   |  37 +-
src/include/catalog/pg_type.h   |   4 +
src/include/utils/inet.h|  22 ++
src/test/regress/expected/macaddr8.out  | 354 ++
src/test/regress/expected/opr_sanity.out|   6 +
src/test/regress/parallel_schedule  |   2 +-
src/test/regress/serial_schedule|   1 +
src/test/regress/sql/macaddr8.sql   |  89 +
37 files changed, 1826 insertions(+), 20 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 +-
contrib/pgstattuple/sql/pgstattuple.sql  | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 return a useful error
message to the user if they mistakenly pass an invalid relation to a
function which doesn't accept that kind of relation.

In passing, improve some of the existing checks to use ereport() instead
of elog(), add a function to consolidate common checks where
appropriate, and add some regression tests.

Author: Amit Langote, with various changes by me
Reviewed by: Michael Paquier and Corey Huinker
Discussion: 
https://postgr.es/m/ab91fd9d-4751-ee77-c87b-4dd704c1e...@lab.ntt.co.jp

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/c08d82f38ebf763b79bd43ae34b7310ee47aaacd

Modified Files
--
contrib/pageinspect/expected/page.out|   9 ++
contrib/pageinspect/rawpage.c|   5 +
contrib/pageinspect/sql/page.sql |   9 ++
contrib/pg_visibility/.gitignore |   4 +
contrib/pg_visibility/Makefile   |   2 +
contrib/pg_visibility/expected/pg_visibility.out | 142 +++
contrib/pg_visibility/pg_visibility.c|  58 ++---
contrib/pg_visibility/sql/pg_visibility.sql  |  83 +
contrib/pgstattuple/expected/pgstattuple.out | 107 +
contrib/pgstattuple/pgstatindex.c|  52 +++--
contrib/pgstattuple/pgstattuple.c|   3 +
contrib/pgstattuple/sql/pgstattuple.sql  |  64 ++
12 files changed, 517 insertions(+), 21 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Expose explain's SUMMARY option

[Stephen Frost]

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 without analyze
will not print the summary lines (just the planning time, currently)
while running explain with analyze will include the summary lines (both
the planning time and the totalled execution time).

Users who wish to see the summary information for plain explain can now
use: EXPLAIN (SUMMARY ON) query;  Users who do not want to have the
summary printed for an analyze run can use:
EXPLAIN (ANALYZE ON, SUMMARY OFF) query;

With this, we can now also have EXPLAIN ANALYZE queries included in our
regression tests by using:
EXPLAIN (ANALYZE ON, TIMING OFF, SUMMARY off) query;

I went ahead and added an example of this, which will hopefully not make
the buildfarm complain.

Author: Ashutosh Bapat
Discussion: 
https://postgr.es/m/cafjfpree5z2h98u2vuia8hcekprrwraurjhmye44hnv8-xk...@mail.gmail.com

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/f9b1a0dd403ec0931213c66d5f979a3d3e8e7e30

Modified Files
--
doc/src/sgml/ref/explain.sgml| 16 
src/backend/commands/explain.c   | 18 +++---
src/backend/commands/prepare.c   |  9 -
src/test/regress/expected/select.out | 10 ++
src/test/regress/sql/select.sql  |  3 +++
5 files changed, 52 insertions(+), 4 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: psql: Add \gx command

[Stephen Frost]

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 doesn't
have to worry about the current state of the expanded variable, or
resetting it later, to ensure a given query is always returned in
expanded mode.

Primairly Christoph's patch, though I did tweak the documentation and help
text a bit, and re-indented the tab completion section.

Author: Christoph Berg
Reviewed By: Daniel Verite
Discussion: 
https://postgr.es/m/20170127132737.6skslelaf4txs6iw%40msg.credativ.de

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/b2678efd43f17db7dfa04e0ca076ea01275cd9bc

Modified Files
--
doc/src/sgml/ref/psql-ref.sgml | 12 
src/bin/psql/command.c |  9 +++--
src/bin/psql/common.c  |  7 +++
src/bin/psql/help.c|  1 +
src/bin/psql/settings.h|  1 +
src/bin/psql/tab-complete.c| 11 ++-
src/test/regress/expected/psql.out | 23 +++
src/test/regress/sql/psql.sql  |  7 +++
8 files changed, 64 insertions(+), 7 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 the public schema.

When running in "--clean" mode, the public schema is dropped and then
recreated and it is recreated with the normal schema-default privileges
of "nothing".  This is unlike how the public schema starts life, which
is to have CREATE and USAGE GRANT'd to the PUBLIC role, and that is what
is recorded in pg_init_privs.

Due to this, in "--clean" mode, pg_dump would mistakenly only dump out
the set of privileges required to go from the initdb-time privileges on
the public schema to whatever the current-state privileges are.  If the
privileges were not changed from initdb time, then no privileges would
be dumped out for the public schema, but with the schema being dropped
and recreated, the result was that the public schema would have no ACLs
on it instead of what it should have, which is the initdb-time
privileges.

Practically speaking, this meant that pg_dump with --clean mode dumping
a database where the ACLs on the public schema were not changed from the
default would, upon restore, result in a public schema with *no*
privileges GRANT'd, not matching the state of the existing database
(where the initdb-time privileges would have been CREATE and USAGE to
the PUBLIC role for the public schema).

To fix, adjust the query in getNamespaces() to ignore the pg_init_privs
entry for the public schema when running in "--clean" mode, meaning that
the privileges for the public schema would be dumped, correctly, as if
it was going from a newly-created schema to the current state (which is,
indeed, what will happen during the restore thanks to the DROP/CREATE).

Only the public schema is handled in this special way by pg_dump, no
other initdb-time objects are dropped/recreated in --clean mode.

Back-patch to 9.6 where the bug was introduced.

Discussion: https://postgr.es/m/3534542.o3cNaKiDID%40techfox

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/e961341cc1491ddf41e9408d9b1d3342df9ea2c2

Modified Files
--
src/bin/pg_dump/pg_dump.c| 22 +-
src/bin/pg_dump/t/002_pg_dump.pl | 26 --
2 files changed, 45 insertions(+), 3 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 the public schema.

When running in "--clean" mode, the public schema is dropped and then
recreated and it is recreated with the normal schema-default privileges
of "nothing".  This is unlike how the public schema starts life, which
is to have CREATE and USAGE GRANT'd to the PUBLIC role, and that is what
is recorded in pg_init_privs.

Due to this, in "--clean" mode, pg_dump would mistakenly only dump out
the set of privileges required to go from the initdb-time privileges on
the public schema to whatever the current-state privileges are.  If the
privileges were not changed from initdb time, then no privileges would
be dumped out for the public schema, but with the schema being dropped
and recreated, the result was that the public schema would have no ACLs
on it instead of what it should have, which is the initdb-time
privileges.

Practically speaking, this meant that pg_dump with --clean mode dumping
a database where the ACLs on the public schema were not changed from the
default would, upon restore, result in a public schema with *no*
privileges GRANT'd, not matching the state of the existing database
(where the initdb-time privileges would have been CREATE and USAGE to
the PUBLIC role for the public schema).

To fix, adjust the query in getNamespaces() to ignore the pg_init_privs
entry for the public schema when running in "--clean" mode, meaning that
the privileges for the public schema would be dumped, correctly, as if
it was going from a newly-created schema to the current state (which is,
indeed, what will happen during the restore thanks to the DROP/CREATE).

Only the public schema is handled in this special way by pg_dump, no
other initdb-time objects are dropped/recreated in --clean mode.

Back-patch to 9.6 where the bug was introduced.

Discussion: https://postgr.es/m/3534542.o3cNaKiDID%40techfox

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/330b84d8c40864007833e05dc9d849c4bda77240

Modified Files
--
src/bin/pg_dump/pg_dump.c| 22 +-
src/bin/pg_dump/t/002_pg_dump.pl | 32 ++--
2 files changed, 51 insertions(+), 3 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 information which can be associated
with large objects.  Currently, we also support COMMENTs and SECURITY
LABELs with large objects and these were being silently dropped during a
pg_upgrade as pg_dump would skip everything having to do with a large
object and pg_upgrade only copied the tables mentioned to the new
cluster.

As the file copies happen after the catalog dump and reload, we can't
simply include the COMMENTs and SECURITY LABELs in pg_dump's binary-mode
output but we also have to include the actual large object definition as
well.  With the definition, comments, and security labels in the pg_dump
output and the file copies performed by pg_upgrade, all of the data and
metadata associated with large objects is able to be successfully pulled
forward across a pg_upgrade.

In 9.6 and master, we can simply adjust the dump bitmask to indicate
which components we don't want.  In 9.5 and earlier, we have to put
explciit checks in in dumpBlob() and dumpBlobs() to not include the ACL
or the data when in binary-upgrade mode.

Adjustments made to the privileges regression test to allow another test
(large_object.sql) to be added which explicitly leaves a large object
with a comment in place to provide coverage of that case with
pg_upgrade.

Back-patch to all supported branches.

Discussion: https://postgr.es/m/20170221162655.ge9...@tamriel.snowman.net

Branch
--
REL9_5_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/6be8647f7862dbbefe4d49d842566738cd753963

Modified Files
--
src/bin/pg_dump/pg_backup.h|  1 +
src/bin/pg_dump/pg_backup_archiver.c   | 12 ++-
src/bin/pg_dump/pg_dump.c  | 34 +-
src/test/regress/expected/large_object.out | 15 +
src/test/regress/expected/privileges.out   |  8 +++
src/test/regress/parallel_schedule |  2 +-
src/test/regress/serial_schedule   |  1 +
src/test/regress/sql/large_object.sql  |  7 ++
src/test/regress/sql/privileges.sql|  6 +++---
9 files changed, 72 insertions(+), 14 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 information which can be associated
with large objects.  Currently, we also support COMMENTs and SECURITY
LABELs with large objects and these were being silently dropped during a
pg_upgrade as pg_dump would skip everything having to do with a large
object and pg_upgrade only copied the tables mentioned to the new
cluster.

As the file copies happen after the catalog dump and reload, we can't
simply include the COMMENTs and SECURITY LABELs in pg_dump's binary-mode
output but we also have to include the actual large object definition as
well.  With the definition, comments, and security labels in the pg_dump
output and the file copies performed by pg_upgrade, all of the data and
metadata associated with large objects is able to be successfully pulled
forward across a pg_upgrade.

In 9.6 and master, we can simply adjust the dump bitmask to indicate
which components we don't want.  In 9.5 and earlier, we have to put
explciit checks in in dumpBlob() and dumpBlobs() to not include the ACL
or the data when in binary-upgrade mode.

Adjustments made to the privileges regression test to allow another test
(large_object.sql) to be added which explicitly leaves a large object
with a comment in place to provide coverage of that case with
pg_upgrade.

Back-patch to all supported branches.

Discussion: https://postgr.es/m/20170221162655.ge9...@tamriel.snowman.net

Branch
--
REL9_4_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/93598898c8d203ef296f4f5870c5f948e9fda416

Modified Files
--
src/bin/pg_dump/pg_backup.h|  1 +
src/bin/pg_dump/pg_backup_archiver.c   | 12 ++-
src/bin/pg_dump/pg_dump.c  | 34 +-
src/test/regress/expected/large_object.out | 15 +
src/test/regress/expected/privileges.out   |  8 +++
src/test/regress/parallel_schedule |  2 +-
src/test/regress/serial_schedule   |  1 +
src/test/regress/sql/large_object.sql  |  7 ++
src/test/regress/sql/privileges.sql|  6 +++---
9 files changed, 72 insertions(+), 14 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 information which can be associated
with large objects.  Currently, we also support COMMENTs and SECURITY
LABELs with large objects and these were being silently dropped during a
pg_upgrade as pg_dump would skip everything having to do with a large
object and pg_upgrade only copied the tables mentioned to the new
cluster.

As the file copies happen after the catalog dump and reload, we can't
simply include the COMMENTs and SECURITY LABELs in pg_dump's binary-mode
output but we also have to include the actual large object definition as
well.  With the definition, comments, and security labels in the pg_dump
output and the file copies performed by pg_upgrade, all of the data and
metadata associated with large objects is able to be successfully pulled
forward across a pg_upgrade.

In 9.6 and master, we can simply adjust the dump bitmask to indicate
which components we don't want.  In 9.5 and earlier, we have to put
explciit checks in in dumpBlob() and dumpBlobs() to not include the ACL
or the data when in binary-upgrade mode.

Adjustments made to the privileges regression test to allow another test
(large_object.sql) to be added which explicitly leaves a large object
with a comment in place to provide coverage of that case with
pg_upgrade.

Back-patch to all supported branches.

Discussion: https://postgr.es/m/20170221162655.ge9...@tamriel.snowman.net

Branch
--
REL9_2_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/e864cd25b4f5a85e0c236cf845daff99433937db

Modified Files
--
src/bin/pg_dump/pg_backup.h|  1 +
src/bin/pg_dump/pg_backup_archiver.c   | 12 ++-
src/bin/pg_dump/pg_dump.c  | 34 +-
src/test/regress/expected/large_object.out | 15 +
src/test/regress/expected/privileges.out   |  8 +++
src/test/regress/parallel_schedule |  2 +-
src/test/regress/serial_schedule   |  1 +
src/test/regress/sql/large_object.sql  |  7 ++
src/test/regress/sql/privileges.sql|  6 +++---
9 files changed, 72 insertions(+), 14 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 information which can be associated
with large objects.  Currently, we also support COMMENTs and SECURITY
LABELs with large objects and these were being silently dropped during a
pg_upgrade as pg_dump would skip everything having to do with a large
object and pg_upgrade only copied the tables mentioned to the new
cluster.

As the file copies happen after the catalog dump and reload, we can't
simply include the COMMENTs and SECURITY LABELs in pg_dump's binary-mode
output but we also have to include the actual large object definition as
well.  With the definition, comments, and security labels in the pg_dump
output and the file copies performed by pg_upgrade, all of the data and
metadata associated with large objects is able to be successfully pulled
forward across a pg_upgrade.

In 9.6 and master, we can simply adjust the dump bitmask to indicate
which components we don't want.  In 9.5 and earlier, we have to put
explciit checks in in dumpBlob() and dumpBlobs() to not include the ACL
or the data when in binary-upgrade mode.

Adjustments made to the privileges regression test to allow another test
(large_object.sql) to be added which explicitly leaves a large object
with a comment in place to provide coverage of that case with
pg_upgrade.

Back-patch to all supported branches.

Discussion: https://postgr.es/m/20170221162655.ge9...@tamriel.snowman.net

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/65a3f233b2cf9aa7750d0c634654a65f4c5579c4

Modified Files
--
src/bin/pg_dump/pg_backup.h|  1 +
src/bin/pg_dump/pg_backup_archiver.c   | 12 +++-
src/bin/pg_dump/pg_dump.c  | 31 +++---
src/test/regress/expected/large_object.out | 15 +++
src/test/regress/expected/privileges.out   |  8 
src/test/regress/parallel_schedule |  2 +-
src/test/regress/serial_schedule   |  1 +
src/test/regress/sql/large_object.sql  |  8 
src/test/regress/sql/privileges.sql|  6 +++---
9 files changed, 72 insertions(+), 12 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 information which can be associated
with large objects.  Currently, we also support COMMENTs and SECURITY
LABELs with large objects and these were being silently dropped during a
pg_upgrade as pg_dump would skip everything having to do with a large
object and pg_upgrade only copied the tables mentioned to the new
cluster.

As the file copies happen after the catalog dump and reload, we can't
simply include the COMMENTs and SECURITY LABELs in pg_dump's binary-mode
output but we also have to include the actual large object definition as
well.  With the definition, comments, and security labels in the pg_dump
output and the file copies performed by pg_upgrade, all of the data and
metadata associated with large objects is able to be successfully pulled
forward across a pg_upgrade.

In 9.6 and master, we can simply adjust the dump bitmask to indicate
which components we don't want.  In 9.5 and earlier, we have to put
explciit checks in in dumpBlob() and dumpBlobs() to not include the ACL
or the data when in binary-upgrade mode.

Adjustments made to the privileges regression test to allow another test
(large_object.sql) to be added which explicitly leaves a large object
with a comment in place to provide coverage of that case with
pg_upgrade.

Back-patch to all supported branches.

Discussion: https://postgr.es/m/20170221162655.ge9...@tamriel.snowman.net

Branch
--
REL9_3_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/7f831f09bb85d93d99f55269479e4b6d105937f8

Modified Files
--
src/bin/pg_dump/pg_backup.h|  1 +
src/bin/pg_dump/pg_backup_archiver.c   | 12 ++-
src/bin/pg_dump/pg_dump.c  | 34 +-
src/test/regress/expected/large_object.out | 15 +
src/test/regress/expected/privileges.out   |  8 +++
src/test/regress/parallel_schedule |  2 +-
src/test/regress/serial_schedule   |  1 +
src/test/regress/sql/large_object.sql  |  7 ++
src/test/regress/sql/privileges.sql|  6 +++---
9 files changed, 72 insertions(+), 14 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 information which can be associated
with large objects.  Currently, we also support COMMENTs and SECURITY
LABELs with large objects and these were being silently dropped during a
pg_upgrade as pg_dump would skip everything having to do with a large
object and pg_upgrade only copied the tables mentioned to the new
cluster.

As the file copies happen after the catalog dump and reload, we can't
simply include the COMMENTs and SECURITY LABELs in pg_dump's binary-mode
output but we also have to include the actual large object definition as
well.  With the definition, comments, and security labels in the pg_dump
output and the file copies performed by pg_upgrade, all of the data and
metadata associated with large objects is able to be successfully pulled
forward across a pg_upgrade.

In 9.6 and master, we can simply adjust the dump bitmask to indicate
which components we don't want.  In 9.5 and earlier, we have to put
explciit checks in in dumpBlob() and dumpBlobs() to not include the ACL
or the data when in binary-upgrade mode.

Adjustments made to the privileges regression test to allow another test
(large_object.sql) to be added which explicitly leaves a large object
with a comment in place to provide coverage of that case with
pg_upgrade.

Back-patch to all supported branches.

Discussion: https://postgr.es/m/20170221162655.ge9...@tamriel.snowman.net

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/ff992c074e308ade204a38eb43a6d19c8403414e

Modified Files
--
src/bin/pg_dump/pg_backup.h|  1 +
src/bin/pg_dump/pg_backup_archiver.c   | 10 +-
src/bin/pg_dump/pg_dump.c  | 31 +++---
src/bin/pg_dump/t/002_pg_dump.pl   | 14 ++
src/test/regress/expected/large_object.out | 15 +++
src/test/regress/expected/privileges.out   |  8 
src/test/regress/parallel_schedule |  2 +-
src/test/regress/serial_schedule   |  1 +
src/test/regress/sql/large_object.sql  |  8 
src/test/regress/sql/privileges.sql|  6 +++---
10 files changed, 80 insertions(+), 16 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 future 9.6 clusters would come out OK, or
> >> possibly we should back-patch some other fix, but that would need more
> >> discussion.
> 
> > I think it would be worth back-patching the catalog fix for future 9.6 
> > clusters as a start.
> 
> Yes, I think it's rather silly not to do so.  We have made comparable
> backpatched fixes multiple times in the past.  What is worth discussing is
> whether there are *additional* things we ought to do in 9.6 to prevent
> misbehavior in installations initdb'd pre-9.6.3.
> 
> If there's a cheap way of testing "AmInParallelWorker", I'd be in favor of
> adding a quick-n-dirty test and ereport(ERROR) to these functions in the
> 9.6 branch, so that at least you get a clean error and not some weird
> misbehavior.  Not sure if there's anything more we can do than that.

That's more-or-less what I was thinking (and suggested to David over IM
a little while ago, actually).  I don't know if there's an easy way to
do such a check, but I don't think it would really need to be
particularly cheap, just not overly complex.  These code paths are
certainly not ones that need to be high-performance.

Thanks!

Stephen


signature.asc
Description: Digital signature

[COMMITTERS] pgsql: Initialize number_of_jobs in NewRestoreOptions

[Stephen Frost]

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: 
https://postgr.es/m/CAGPqQf2u1T3J=anhcw1cuvzqjd80owvmg2-2wmfg08gcm9h...@mail.gmail.com

Branch
--
REL9_2_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/0021ce274319215fdc481ae29f059068f7a5bf0a

Modified Files
--
src/bin/pg_dump/pg_backup_archiver.c | 1 +
1 file changed, 1 insertion(+)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 place.

Unfortunately, the DEFAULT PRIVILEGES system didn't quite get the
correct treatment with this change and ended up (incorrectly) only
including positive GRANTs instead of both the REVOKEs and GRANTs
necessary to preserve the correct privileges.

There are only a couple cases where such REVOKEs are possible because,
generally speaking, there's few rights which exist on objects by
default to be revoked.

Examples of REVOKEs which weren't being correctly preserved are when
privileges are REVOKE'd from the creator/owner, like so:

ALTER DEFAULT PRIVILEGES
  FOR ROLE myrole
  REVOKE SELECT ON TABLES FROM myrole;

or when other default privileges are being revoked, such as EXECUTE
rights granted to public for functions:

ALTER DEFAULT PRIVILEGES
  FOR ROLE myrole
  REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC;

Fix this by correctly working out what the correct REVOKE statements are
(if any) and dump them out, just as we do for everything else.

Noticed while developing additional regression tests for pg_dump, which
will be landing shortly.

Back-patch to 9.6 where the bug was introduced.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/e2090d9d20d8091c9478a674d9c22fc8006909ce

Modified Files
--
src/bin/pg_dump/dumputils.c | 23 -
src/bin/pg_dump/dumputils.h |  4 ++-
src/bin/pg_dump/pg_dump.c   | 63 -
src/bin/pg_dump/pg_dump.h   |  3 +++
4 files changed, 78 insertions(+), 15 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 place.

Unfortunately, the DEFAULT PRIVILEGES system didn't quite get the
correct treatment with this change and ended up (incorrectly) only
including positive GRANTs instead of both the REVOKEs and GRANTs
necessary to preserve the correct privileges.

There are only a couple cases where such REVOKEs are possible because,
generally speaking, there's few rights which exist on objects by
default to be revoked.

Examples of REVOKEs which weren't being correctly preserved are when
privileges are REVOKE'd from the creator/owner, like so:

ALTER DEFAULT PRIVILEGES
  FOR ROLE myrole
  REVOKE SELECT ON TABLES FROM myrole;

or when other default privileges are being revoked, such as EXECUTE
rights granted to public for functions:

ALTER DEFAULT PRIVILEGES
  FOR ROLE myrole
  REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC;

Fix this by correctly working out what the correct REVOKE statements are
(if any) and dump them out, just as we do for everything else.

Noticed while developing additional regression tests for pg_dump, which
will be landing shortly.

Back-patch to 9.6 where the bug was introduced.

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/eb5e9d90df7536d0cf5c0d669d874f91b7be36d6

Modified Files
--
src/bin/pg_dump/dumputils.c | 23 -
src/bin/pg_dump/dumputils.h |  4 ++-
src/bin/pg_dump/pg_dump.c   | 63 -
src/bin/pg_dump/pg_dump.h   |  3 +++
4 files changed, 78 insertions(+), 15 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: perltidy pg_dump TAP tests

[Stephen Frost]

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 from
"-f" to "--file=", and similar.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/6af8b89adba16f97bee0d3b01256861e10d0e4f1

Modified Files
--
src/bin/pg_dump/t/001_basic.pl|  14 +-
src/bin/pg_dump/t/002_pg_dump.pl  | 727 +-
src/bin/pg_dump/t/010_dump_connstr.pl | 169 
3 files changed, 477 insertions(+), 433 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: test_pg_dump: perltidy cleanup

[Stephen Frost]

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 single arguments (eg: -f file.sql changed to be
--file=file.sql) to avoid having them confusingly split across lines due
to perltidy.

Back-patch to 9.6, as the last patch was.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/58da8334308c26107ebb7ee06c99589e14bd882b

Modified Files
--
src/test/modules/test_pg_dump/t/001_base.pl | 885 
1 file changed, 377 insertions(+), 508 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: test_pg_dump: perltidy cleanup

[Stephen Frost]

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 single arguments (eg: -f file.sql changed to be
--file=file.sql) to avoid having them confusingly split across lines due
to perltidy.

Back-patch to 9.6, as the last patch was.

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/3e9c36165377b07ffb182c366e295ac48ea5d5ba

Modified Files
--
src/test/modules/test_pg_dump/t/001_base.pl | 885 
1 file changed, 377 insertions(+), 508 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

* 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 than it
> > really should have been to add new tests or adjust what tests are for
> > what runs, etc.
> > 
> > Reformat to clean that all up.
> > 
> > Whitespace-only changes.
> 
> This will be undone by the next perltidy run.

Ugh.

I certainly hope what was there before wasn't the result of a perltidy
run as it was quite ugly and inconsistent..

Thanks!

Stephen


signature.asc
Description: Digital signature

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

[Stephen Frost]

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 extension to be changed after the
initial CREATE EXTENSION script has been run.

The result of this meant that ACLs for objects added through
ALTER EXTENSION ADD were not recorded into pg_init_privs and we would
end up including those ACLs in pg_dump when we shouldn't have.

This commit corrects that by making sure to have pg_init_privs updated
when ALTER EXTENSION ADD/DROP is run, recording the permissions as they
are at ALTER EXTENSION ADD time, and removing any if/when ALTER
EXTENSION DROP is called.

This issue was pointed out by Moshe Jacobson as commentary on bug #14456
(which was actually a bug about versions prior to 9.6 not handling
custom ACLs on extensions correctly, an issue now addressed with
pg_init_privs in 9.6).

Back-patch to 9.6 where pg_init_privs was introduced.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/e54f75722c720b596ec5e72154cc899da199de5b

Modified Files
--
src/backend/catalog/aclchk.c   | 436 +++--
src/backend/commands/extension.c   |  21 +
src/include/utils/acl.h|   4 +
.../modules/test_pg_dump/expected/test_pg_dump.out | 100 -
src/test/modules/test_pg_dump/sql/test_pg_dump.sql | 108 -
src/test/modules/test_pg_dump/t/001_base.pl|  92 +
6 files changed, 732 insertions(+), 29 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 extension to be changed after the
initial CREATE EXTENSION script has been run.

The result of this meant that ACLs for objects added through
ALTER EXTENSION ADD were not recorded into pg_init_privs and we would
end up including those ACLs in pg_dump when we shouldn't have.

This commit corrects that by making sure to have pg_init_privs updated
when ALTER EXTENSION ADD/DROP is run, recording the permissions as they
are at ALTER EXTENSION ADD time, and removing any if/when ALTER
EXTENSION DROP is called.

This issue was pointed out by Moshe Jacobson as commentary on bug #14456
(which was actually a bug about versions prior to 9.6 not handling
custom ACLs on extensions correctly, an issue now addressed with
pg_init_privs in 9.6).

Back-patch to 9.6 where pg_init_privs was introduced.

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/20064c0ec201fd2302757c1fdb2279e9dc9a4030

Modified Files
--
src/backend/catalog/aclchk.c   | 436 +++--
src/backend/commands/extension.c   |  21 +
src/include/utils/acl.h|   4 +
.../modules/test_pg_dump/expected/test_pg_dump.out | 100 -
src/test/modules/test_pg_dump/sql/test_pg_dump.sql | 108 -
src/test/modules/test_pg_dump/t/001_base.pl|  92 +
6 files changed, 732 insertions(+), 29 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: test_pg_dump TAP test whitespace cleanup

[Stephen Frost]

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 up.

Whitespace-only changes.

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/73cd4896f41052bdaf779fa1b63aca5f10c56a62

Modified Files
--
src/test/modules/test_pg_dump/t/001_base.pl | 784 
1 file changed, 462 insertions(+), 322 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: test_pg_dump TAP test whitespace cleanup

[Stephen Frost]

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 up.

Whitespace-only changes.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/fb94ca77f1400e236b00d432dccfbe4f1124971c

Modified Files
--
src/test/modules/test_pg_dump/t/001_base.pl | 784 
1 file changed, 462 insertions(+), 322 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Logical replication

[Stephen Frost]

* 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 issue in pg_upgrade / pg_dump.

Thanks!

Stephen


signature.asc
Description: Digital signature

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

[Stephen Frost]

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 by processExtensionTables() because it's
a config sequence.  In that case, the sequence itself won't be marked as
dumping data because it's part of an extension, leading to the need for
processExtensionTables() to create the sequence data entry.

This leads to extension config sequence data not being included in the
dump when it should be.  Fix this by looking at the sequence data's dump
flag instead, just as dumpTableData() was doing for tables (which is why
config tables were correctly being handled), and add a regression test
to make sure we don't break it moving forward.

All of this is a bit round-about since we can now represent which
components of a given dump item should be dumped out through the dump
flag.  A future improvement might be to change checkExtensionMembership()
to check for config sequences/tables and set the dump flag based on that
directly, possibly removing the need for processExtensionTables().

Bug found by Daniele Varrazzo.

Discussion: 
https://postgr.es/m/CA+mi_8ZmxQM7+nZ7pJ8uyfxc9V3o=uag14dvqvftdmvw8oj...@mail.gmail.com

Patch by Michael Paquier, with some tweaking of the regression tests by
me.

Back-patch to 9.6 where the bug was introduced.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/bec96c82f8ff4fcf7ef0f070f6f7447edf106de3

Modified Files
--
src/bin/pg_dump/pg_dump.c   |  2 +-
src/test/modules/test_pg_dump/t/001_base.pl | 19 +++
src/test/modules/test_pg_dump/test_pg_dump--1.0.sql |  3 +++
3 files changed, 23 insertions(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 by processExtensionTables() because it's
a config sequence.  In that case, the sequence itself won't be marked as
dumping data because it's part of an extension, leading to the need for
processExtensionTables() to create the sequence data entry.

This leads to extension config sequence data not being included in the
dump when it should be.  Fix this by looking at the sequence data's dump
flag instead, just as dumpTableData() was doing for tables (which is why
config tables were correctly being handled), and add a regression test
to make sure we don't break it moving forward.

All of this is a bit round-about since we can now represent which
components of a given dump item should be dumped out through the dump
flag.  A future improvement might be to change checkExtensionMembership()
to check for config sequences/tables and set the dump flag based on that
directly, possibly removing the need for processExtensionTables().

Bug found by Daniele Varrazzo.

Discussion: 
https://postgr.es/m/CA+mi_8ZmxQM7+nZ7pJ8uyfxc9V3o=uag14dvqvftdmvw8oj...@mail.gmail.com

Patch by Michael Paquier, with some tweaking of the regression tests by
me.

Back-patch to 9.6 where the bug was introduced.

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/fd081cabf7c3ce514d28e8de1a9b5c8717ea1130

Modified Files
--
src/bin/pg_dump/pg_dump.c   |  2 +-
src/test/modules/test_pg_dump/t/001_base.pl | 19 +++
src/test/modules/test_pg_dump/test_pg_dump--1.0.sql |  3 +++
3 files changed, 23 insertions(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

* 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():
> 
> > Hm.  I seem to recall trying to avoid having the hard-coded value there
> > but we don't have BOOTSTRAP_SUPERUSERID defined somewhere that initdb.c
> > could include it from, do we?  It's only in catalog/pg_authid.h.
> 
> Looks to me like including catalog/pg_authid.h in initdb would work fine.
> pg_upgrade does it.

Ah, alright then.  I'm happy to let whomever make that change, or, if no
one else wants to, I'll do it since I'm the author of those lines.

Thanks!

Stephen


signature.asc
Description: Digital signature

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

[Stephen Frost]

* 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
> >> usernames.  Perhaps follow this model instead:
> 
> > We could just use the numeric value, like in the attached patch.
> 
> WFM.  Btw, I noticed that BOOTSTRAP_SUPERUSERID is hard-coded as "10"
> in this bit in setup_privileges():
> 
>   " (SELECT E'=r/\"$POSTGRES_SUPERUSERNAME\"' as acl "
>   "  UNION SELECT unnest(pg_catalog.acldefault("
>   "CASE WHEN relkind = 'S' THEN 's' ELSE 'r' 
> END::\"char\",10::oid))"
>   " ) as a) "
> 
> Is there a reasonable way to fix that?  Maybe do another replace_token
> call for it?

Hm.  I seem to recall trying to avoid having the hard-coded value there
but we don't have BOOTSTRAP_SUPERUSERID defined somewhere that initdb.c
could include it from, do we?  It's only in catalog/pg_authid.h.

We could re-define it in initdb.c, of course, and perhaps that'd be
better than having it hard-coded.  I'm not sure that we really want to
expose BOOTSTRAP_SUPERUSERID to regular client code, or create some
additional set of headers which are just for initdb and the backend..

Of course, I might be missing something here, but I'm pretty sure that
was my thinking when I wrote that code.

Thanks!

Stephen


signature.asc
Description: Digital signature

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

[Stephen Frost]

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
--single-transaction), leading to potentially completely unexpected
results from a command line such as:

  -> pg_restore -j -1

Where a user would get neither parallel jobs nor a single-transaction.

Add in validity checking of the parallel jobs option, as we already have
in pg_dump, before we try to open up the archive.  Also move the check
that we haven't been asked to run more parallel jobs than possible on
Windows to the same place, so we do all the option validity checking
before opening the archive.

Back-patch all the way, though for 9.2 we're adding the Windows-specific
check against MAXIMUM_WAIT_OBJECTS as that check wasn't back-patched
originally.

Discussion: 
https://www.postgresql.org/message-id/20170110044815.GC18360%40tamriel.snowman.net

Branch
--
REL9_5_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/26e7cdb3a80d340742aeb5bfe2dbc42edfb9d34b

Modified Files
--
src/bin/pg_dump/pg_restore.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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
--single-transaction), leading to potentially completely unexpected
results from a command line such as:

  -> pg_restore -j -1

Where a user would get neither parallel jobs nor a single-transaction.

Add in validity checking of the parallel jobs option, as we already have
in pg_dump, before we try to open up the archive.  Also move the check
that we haven't been asked to run more parallel jobs than possible on
Windows to the same place, so we do all the option validity checking
before opening the archive.

Back-patch all the way, though for 9.2 we're adding the Windows-specific
check against MAXIMUM_WAIT_OBJECTS as that check wasn't back-patched
originally.

Discussion: 
https://www.postgresql.org/message-id/20170110044815.GC18360%40tamriel.snowman.net

Branch
--
REL9_2_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/c59a1a89035674c6efacc596d652528cebba37ec

Modified Files
--
src/bin/pg_dump/pg_restore.c | 16 
1 file changed, 16 insertions(+)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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
--single-transaction), leading to potentially completely unexpected
results from a command line such as:

  -> pg_restore -j -1

Where a user would get neither parallel jobs nor a single-transaction.

Add in validity checking of the parallel jobs option, as we already have
in pg_dump, before we try to open up the archive.  Also move the check
that we haven't been asked to run more parallel jobs than possible on
Windows to the same place, so we do all the option validity checking
before opening the archive.

Back-patch all the way, though for 9.2 we're adding the Windows-specific
check against MAXIMUM_WAIT_OBJECTS as that check wasn't back-patched
originally.

Discussion: 
https://www.postgresql.org/message-id/20170110044815.GC18360%40tamriel.snowman.net

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/4b5f399177ecd1ae0e94606fc7c251931c5987b6

Modified Files
--
src/bin/pg_dump/pg_restore.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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
--single-transaction), leading to potentially completely unexpected
results from a command line such as:

  -> pg_restore -j -1

Where a user would get neither parallel jobs nor a single-transaction.

Add in validity checking of the parallel jobs option, as we already have
in pg_dump, before we try to open up the archive.  Also move the check
that we haven't been asked to run more parallel jobs than possible on
Windows to the same place, so we do all the option validity checking
before opening the archive.

Back-patch all the way, though for 9.2 we're adding the Windows-specific
check against MAXIMUM_WAIT_OBJECTS as that check wasn't back-patched
originally.

Discussion: 
https://www.postgresql.org/message-id/20170110044815.GC18360%40tamriel.snowman.net

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/e72059f3757594c5530ce321acdbe67f0da5da13

Modified Files
--
src/bin/pg_dump/pg_restore.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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
--single-transaction), leading to potentially completely unexpected
results from a command line such as:

  -> pg_restore -j -1

Where a user would get neither parallel jobs nor a single-transaction.

Add in validity checking of the parallel jobs option, as we already have
in pg_dump, before we try to open up the archive.  Also move the check
that we haven't been asked to run more parallel jobs than possible on
Windows to the same place, so we do all the option validity checking
before opening the archive.

Back-patch all the way, though for 9.2 we're adding the Windows-specific
check against MAXIMUM_WAIT_OBJECTS as that check wasn't back-patched
originally.

Discussion: 
https://www.postgresql.org/message-id/20170110044815.GC18360%40tamriel.snowman.net

Branch
--
REL9_4_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/2c72d9c5e3f2f292ebcc30a37755d87b605c7fd5

Modified Files
--
src/bin/pg_dump/pg_restore.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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
--single-transaction), leading to potentially completely unexpected
results from a command line such as:

  -> pg_restore -j -1

Where a user would get neither parallel jobs nor a single-transaction.

Add in validity checking of the parallel jobs option, as we already have
in pg_dump, before we try to open up the archive.  Also move the check
that we haven't been asked to run more parallel jobs than possible on
Windows to the same place, so we do all the option validity checking
before opening the archive.

Back-patch all the way, though for 9.2 we're adding the Windows-specific
check against MAXIMUM_WAIT_OBJECTS as that check wasn't back-patched
originally.

Discussion: 
https://www.postgresql.org/message-id/20170110044815.GC18360%40tamriel.snowman.net

Branch
--
REL9_3_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/4779d6ca20f7ce89c61b7729a6c714a258586d75

Modified Files
--
src/bin/pg_dump/pg_restore.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 --strict-names --schema='nonexistant*'
  pg_dump: no matching tables were found for pattern "nonexistant*"

Fix that by changing the error message to say 'schemas' instead, since
that is what we are actually complaining about.

Noticed while testing pg_dump error cases.

Back-patch to 9.6 where --strict-names and this error message were
introduced.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/abfd0095c1e1a2e3fad2696516b64871895334ec

Modified Files
--
src/bin/pg_dump/pg_dump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 --strict-names --schema='nonexistant*'
  pg_dump: no matching tables were found for pattern "nonexistant*"

Fix that by changing the error message to say 'schemas' instead, since
that is what we are actually complaining about.

Noticed while testing pg_dump error cases.

Back-patch to 9.6 where --strict-names and this error message were
introduced.

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/22a85b3fbe85a9f1c92de90192de001b7394b4fe

Modified Files
--
src/bin/pg_dump/pg_dump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 various pg_dump error cases.

Back-patch to 9.3 where parallel pg_dump was added.

Branch
--
REL9_5_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/f12681079020eea53ea9a0eb994ac2ee6190770f

Modified Files
--
src/bin/pg_dump/pg_dump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 various pg_dump error cases.

Back-patch to 9.3 where parallel pg_dump was added.

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/96f2344f381df94fcb9b84bffc58bbc540edd842

Modified Files
--
src/bin/pg_dump/pg_dump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 various pg_dump error cases.

Back-patch to 9.3 where parallel pg_dump was added.

Branch
--
REL9_3_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/7cda702363e8bfb61409bb8cbae13689b19f1648

Modified Files
--
src/bin/pg_dump/pg_dump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 various pg_dump error cases.

Back-patch to 9.3 where parallel pg_dump was added.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/2ef6fe9cbae9fe7789a35cbc5fa1bbf78c163d42

Modified Files
--
src/bin/pg_dump/pg_dump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 various pg_dump error cases.

Back-patch to 9.3 where parallel pg_dump was added.

Branch
--
REL9_4_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/499606c806c387ba2f9a9ee773e6b92d99e27221

Modified Files
--
src/bin/pg_dump/pg_dump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 pg_restore/pg_dumpall.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/9b815a8ff227e62442259e0fbabc5cf37e433df9

Modified Files
--
src/bin/pg_dump/t/001_basic.pl   | 61 +++-
src/bin/pg_dump/t/002_pg_dump.pl |  8 +++---
2 files changed, 64 insertions(+), 5 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 removed that check.

Pointed out by Coverity.  Initial patch from Michael Paquier.

Back-patch to 9.6, where that commit had removed the check.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/d74ecbc8d85eb7a2aa1d5516c5c38d6ab0cbbd82

Modified Files
--
src/bin/pg_dump/pg_dump.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 removed that check.

Pointed out by Coverity.  Initial patch from Michael Paquier.

Back-patch to 9.6, where that commit had removed the check.

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/8b1bf3161b360003182997b4e258b8fac78c3bdf

Modified Files
--
src/bin/pg_dump/pg_dump.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Update copyright for 2017

[Stephen Frost]

* 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
> >> work.  Sorry.
> 
> > Shouldn't you check the results of something like this before pushing?
> > Sorry for piling on, but that seems like a quite critical step.
> 
> Actually, my takeaway from this was "don't ever use git reset on the repo".
> "git revert" would have been much safer.  Yeah, it would have meant that
> git blame on the 9.2 branch would have some useless noise, but how much
> does anyone still care about that?

+1.

Thanks!

Stephen


signature.asc
Description: Digital signature

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

[Stephen Frost]

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 out by Daniel Westermann.

Back-patch to all supported branches.

Discussion: 
https://www.postgresql.org/message-id/2020970042.4589542.1482482101585.JavaMail.zimbra%40dbi-services.com

Branch
--
REL9_3_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/376d05f1db0601c018d96ba789b13184df6ec4dd

Modified Files
--
src/bin/pg_dump/pg_dumpall.c | 1 +
1 file changed, 1 insertion(+)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 out by Daniel Westermann.

Back-patch to all supported branches.

Discussion: 
https://www.postgresql.org/message-id/2020970042.4589542.1482482101585.JavaMail.zimbra%40dbi-services.com

Branch
--
REL9_2_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/071538f3491d3d055a7574b8cd38a40b084a01e4

Modified Files
--
src/bin/pg_dump/pg_dumpall.c | 1 +
1 file changed, 1 insertion(+)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 out by Daniel Westermann.

Back-patch to all supported branches.

Discussion: 
https://www.postgresql.org/message-id/2020970042.4589542.1482482101585.JavaMail.zimbra%40dbi-services.com

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/d51af6570520a457a2177edb6df0471c492c3bc0

Modified Files
--
src/bin/pg_dump/pg_dumpall.c | 1 +
1 file changed, 1 insertion(+)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 out by Daniel Westermann.

Back-patch to all supported branches.

Discussion: 
https://www.postgresql.org/message-id/2020970042.4589542.1482482101585.JavaMail.zimbra%40dbi-services.com

Branch
--
REL9_5_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/846eaadd059aa6953b90ad7f2f6f16a965013748

Modified Files
--
src/bin/pg_dump/pg_dumpall.c | 1 +
1 file changed, 1 insertion(+)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 out by Daniel Westermann.

Back-patch to all supported branches.

Discussion: 
https://www.postgresql.org/message-id/2020970042.4589542.1482482101585.JavaMail.zimbra%40dbi-services.com

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/86d216c77549e200b95bed487b6fb87d99a1e789

Modified Files
--
src/bin/pg_dump/pg_dumpall.c | 1 +
1 file changed, 1 insertion(+)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 out by Daniel Westermann.

Back-patch to all supported branches.

Discussion: 
https://www.postgresql.org/message-id/2020970042.4589542.1482482101585.JavaMail.zimbra%40dbi-services.com

Branch
--
REL9_4_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/2ed97140c743b4a4cf725a9d1b54439d7a8dac22

Modified Files
--
src/bin/pg_dump/pg_dumpall.c | 1 +
1 file changed, 1 insertion(+)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

* 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
> > instead were completeing to what 'GRANT X ON' supports, which isn't the
> > ssame at all.
> 
> /me scratches head.

'ALTER DEFAULT PRIVILEGES ... GRANT X ON' can be followed by the literal
term 'TABLES', or 'FUNCTIONS', etc.

'GRANT X ON ' can be followed by an actual table.

A bit awkward to write out in a single sentence though.

Thanks!

Stephen


signature.asc
Description: Digital signature

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

[Stephen Frost]

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 tab completion was only working for one or
the other.  Lastly, we weren't using the actual list of allowed kinds of
objects for default privileges for completion after the 'GRANT X ON' but
instead were completeing to what 'GRANT X ON' supports, which isn't the
ssame at all.

Address these issues by improving the forward tab-completion for ALTER
DEFAULT PRIVILEGES and then constrain and correct how the tail
completion is done when it is for ALTER DEFAULT PRIVILEGES.

Back-patch the forward/tail tab-completion to 9.6, where we made it easy
to handle such cases.

For 9.5 and earlier, correct the initial tab-completion to at least be
correct as far as it goes and then add a check for GRANT/REVOKE to only
tab-complete when the GRANT/REVOKE is the start of the command, so we
don't try to do tab-completion after we get to the GRANT/REVOKE part of
the ALTER DEFAULT PRIVILEGES command, which is better than providing
incorrect completions.

Initial patch for master and 9.6 by Gilles Darold, though I cleaned it
up and added a few comments.  All bugs in the 9.5 and earlier patch are
mine.

Discussion: 
https://www.postgresql.org/message-id/1614593c-e356-5b27-6dba-66320a9bc...@dalibo.com

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/dc61580bd9a6ad869478c9e6f7ba76cb6314f864

Modified Files
--
src/bin/psql/tab-complete.c | 57 ++---
1 file changed, 48 insertions(+), 9 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 tab completion was only working for one or
the other.  Lastly, we weren't using the actual list of allowed kinds of
objects for default privileges for completion after the 'GRANT X ON' but
instead were completeing to what 'GRANT X ON' supports, which isn't the
ssame at all.

Address these issues by improving the forward tab-completion for ALTER
DEFAULT PRIVILEGES and then constrain and correct how the tail
completion is done when it is for ALTER DEFAULT PRIVILEGES.

Back-patch the forward/tail tab-completion to 9.6, where we made it easy
to handle such cases.

For 9.5 and earlier, correct the initial tab-completion to at least be
correct as far as it goes and then add a check for GRANT/REVOKE to only
tab-complete when the GRANT/REVOKE is the start of the command, so we
don't try to do tab-completion after we get to the GRANT/REVOKE part of
the ALTER DEFAULT PRIVILEGES command, which is better than providing
incorrect completions.

Initial patch for master and 9.6 by Gilles Darold, though I cleaned it
up and added a few comments.  All bugs in the 9.5 and earlier patch are
mine.

Discussion: 
https://www.postgresql.org/message-id/1614593c-e356-5b27-6dba-66320a9bc...@dalibo.com

Branch
--
REL9_2_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/26b55d669092e8b69104f49d16f8cc250a7a41ee

Modified Files
--
src/bin/psql/tab-complete.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 tab completion was only working for one or
the other.  Lastly, we weren't using the actual list of allowed kinds of
objects for default privileges for completion after the 'GRANT X ON' but
instead were completeing to what 'GRANT X ON' supports, which isn't the
ssame at all.

Address these issues by improving the forward tab-completion for ALTER
DEFAULT PRIVILEGES and then constrain and correct how the tail
completion is done when it is for ALTER DEFAULT PRIVILEGES.

Back-patch the forward/tail tab-completion to 9.6, where we made it easy
to handle such cases.

For 9.5 and earlier, correct the initial tab-completion to at least be
correct as far as it goes and then add a check for GRANT/REVOKE to only
tab-complete when the GRANT/REVOKE is the start of the command, so we
don't try to do tab-completion after we get to the GRANT/REVOKE part of
the ALTER DEFAULT PRIVILEGES command, which is better than providing
incorrect completions.

Initial patch for master and 9.6 by Gilles Darold, though I cleaned it
up and added a few comments.  All bugs in the 9.5 and earlier patch are
mine.

Discussion: 
https://www.postgresql.org/message-id/1614593c-e356-5b27-6dba-66320a9bc...@dalibo.com

Branch
--
REL9_5_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/16a2efdb28dfdbf705fcf7b95c981847cad7234d

Modified Files
--
src/bin/psql/tab-complete.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 tab completion was only working for one or
the other.  Lastly, we weren't using the actual list of allowed kinds of
objects for default privileges for completion after the 'GRANT X ON' but
instead were completeing to what 'GRANT X ON' supports, which isn't the
ssame at all.

Address these issues by improving the forward tab-completion for ALTER
DEFAULT PRIVILEGES and then constrain and correct how the tail
completion is done when it is for ALTER DEFAULT PRIVILEGES.

Back-patch the forward/tail tab-completion to 9.6, where we made it easy
to handle such cases.

For 9.5 and earlier, correct the initial tab-completion to at least be
correct as far as it goes and then add a check for GRANT/REVOKE to only
tab-complete when the GRANT/REVOKE is the start of the command, so we
don't try to do tab-completion after we get to the GRANT/REVOKE part of
the ALTER DEFAULT PRIVILEGES command, which is better than providing
incorrect completions.

Initial patch for master and 9.6 by Gilles Darold, though I cleaned it
up and added a few comments.  All bugs in the 9.5 and earlier patch are
mine.

Discussion: 
https://www.postgresql.org/message-id/1614593c-e356-5b27-6dba-66320a9bc...@dalibo.com

Branch
--
REL9_3_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/2022d594da3233dca4a4570b1e4e5d8a83ff6163

Modified Files
--
src/bin/psql/tab-complete.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 tab completion was only working for one or
the other.  Lastly, we weren't using the actual list of allowed kinds of
objects for default privileges for completion after the 'GRANT X ON' but
instead were completeing to what 'GRANT X ON' supports, which isn't the
ssame at all.

Address these issues by improving the forward tab-completion for ALTER
DEFAULT PRIVILEGES and then constrain and correct how the tail
completion is done when it is for ALTER DEFAULT PRIVILEGES.

Back-patch the forward/tail tab-completion to 9.6, where we made it easy
to handle such cases.

For 9.5 and earlier, correct the initial tab-completion to at least be
correct as far as it goes and then add a check for GRANT/REVOKE to only
tab-complete when the GRANT/REVOKE is the start of the command, so we
don't try to do tab-completion after we get to the GRANT/REVOKE part of
the ALTER DEFAULT PRIVILEGES command, which is better than providing
incorrect completions.

Initial patch for master and 9.6 by Gilles Darold, though I cleaned it
up and added a few comments.  All bugs in the 9.5 and earlier patch are
mine.

Discussion: 
https://www.postgresql.org/message-id/1614593c-e356-5b27-6dba-66320a9bc...@dalibo.com

Branch
--
REL9_4_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/98f30a0e7d483402f2a7ebe5e6bba044c42c

Modified Files
--
src/bin/psql/tab-complete.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Stephen Frost]

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 tab completion was only working for one or
the other.  Lastly, we weren't using the actual list of allowed kinds of
objects for default privileges for completion after the 'GRANT X ON' but
instead were completeing to what 'GRANT X ON' supports, which isn't the
ssame at all.

Address these issues by improving the forward tab-completion for ALTER
DEFAULT PRIVILEGES and then constrain and correct how the tail
completion is done when it is for ALTER DEFAULT PRIVILEGES.

Back-patch the forward/tail tab-completion to 9.6, where we made it easy
to handle such cases.

For 9.5 and earlier, correct the initial tab-completion to at least be
correct as far as it goes and then add a check for GRANT/REVOKE to only
tab-complete when the GRANT/REVOKE is the start of the command, so we
don't try to do tab-completion after we get to the GRANT/REVOKE part of
the ALTER DEFAULT PRIVILEGES command, which is better than providing
incorrect completions.

Initial patch for master and 9.6 by Gilles Darold, though I cleaned it
up and added a few comments.  All bugs in the 9.5 and earlier patch are
mine.

Discussion: 
https://www.postgresql.org/message-id/1614593c-e356-5b27-6dba-66320a9bc...@dalibo.com

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/f3fd531a51df2a73d8517a542e6999e0186e586b

Modified Files
--
src/bin/psql/tab-complete.c | 57 ++---
1 file changed, 48 insertions(+), 9 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Use TSConfigRelationId in AlterTSConfiguration()

[Stephen Frost]

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 AlterTSConfiguration(), we're
saving information about the command via
EventTriggerCollectAlterTSConfig(), so we should be setting
commandCollected to true.  Also add a regression test to
test_ddl_deparse for ALTER TEXT SEARCH CONFIGURATION.

Author: Artur Zakirov, a few additional comments by me
Discussion: 
https://www.postgresql.org/message-id/57a71eba-f2c7-e7fd-6fc0-2126ec0b39bd%40postgrespro.ru

Back-patch the fix for the InvokeObjectPostAlterHook() call to 9.3 where
it was introduced, and the fix for the ObjectAddressSet() call and
setting commandCollected to true to 9.5 where those changes to
ProcessUtilitySlow() were introduced.

Branch
--
REL9_5_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/e8236921773dab92f884db2685aee49fdc747cfc

Modified Files
--
src/backend/commands/tsearchcmds.c | 4 ++--
src/backend/tcop/utility.c | 8 +++-
src/test/modules/test_ddl_deparse/Makefile | 1 +
src/test/modules/test_ddl_deparse/expected/alter_ts_config.out | 8 
src/test/modules/test_ddl_deparse/sql/alter_ts_config.sql  | 8 
5 files changed, 26 insertions(+), 3 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Use TSConfigRelationId in AlterTSConfiguration()

[Stephen Frost]

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 AlterTSConfiguration(), we're
saving information about the command via
EventTriggerCollectAlterTSConfig(), so we should be setting
commandCollected to true.  Also add a regression test to
test_ddl_deparse for ALTER TEXT SEARCH CONFIGURATION.

Author: Artur Zakirov, a few additional comments by me
Discussion: 
https://www.postgresql.org/message-id/57a71eba-f2c7-e7fd-6fc0-2126ec0b39bd%40postgrespro.ru

Back-patch the fix for the InvokeObjectPostAlterHook() call to 9.3 where
it was introduced, and the fix for the ObjectAddressSet() call and
setting commandCollected to true to 9.5 where those changes to
ProcessUtilitySlow() were introduced.

Branch
--
REL9_4_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/ac1ec9c1f0365293e9fdc26f06545b3b48817230

Modified Files
--
src/backend/commands/tsearchcmds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Use TSConfigRelationId in AlterTSConfiguration()

[Stephen Frost]

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 AlterTSConfiguration(), we're
saving information about the command via
EventTriggerCollectAlterTSConfig(), so we should be setting
commandCollected to true.  Also add a regression test to
test_ddl_deparse for ALTER TEXT SEARCH CONFIGURATION.

Author: Artur Zakirov, a few additional comments by me
Discussion: 
https://www.postgresql.org/message-id/57a71eba-f2c7-e7fd-6fc0-2126ec0b39bd%40postgrespro.ru

Back-patch the fix for the InvokeObjectPostAlterHook() call to 9.3 where
it was introduced, and the fix for the ObjectAddressSet() call and
setting commandCollected to true to 9.5 where those changes to
ProcessUtilitySlow() were introduced.

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/f0f2e56ac28c05f930ca76c432d61909c9a12cdb

Modified Files
--
src/backend/commands/tsearchcmds.c | 4 ++--
src/backend/tcop/utility.c | 8 +++-
src/test/modules/test_ddl_deparse/Makefile | 1 +
src/test/modules/test_ddl_deparse/expected/alter_ts_config.out | 8 
src/test/modules/test_ddl_deparse/sql/alter_ts_config.sql  | 8 
5 files changed, 26 insertions(+), 3 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Use TSConfigRelationId in AlterTSConfiguration()

[Stephen Frost]

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 AlterTSConfiguration(), we're
saving information about the command via
EventTriggerCollectAlterTSConfig(), so we should be setting
commandCollected to true.  Also add a regression test to
test_ddl_deparse for ALTER TEXT SEARCH CONFIGURATION.

Author: Artur Zakirov, a few additional comments by me
Discussion: 
https://www.postgresql.org/message-id/57a71eba-f2c7-e7fd-6fc0-2126ec0b39bd%40postgrespro.ru

Back-patch the fix for the InvokeObjectPostAlterHook() call to 9.3 where
it was introduced, and the fix for the ObjectAddressSet() call and
setting commandCollected to true to 9.5 where those changes to
ProcessUtilitySlow() were introduced.

Branch
--
REL9_3_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/0e3aadb682f0c76f6b21ac0058e3717eb7cc2b19

Modified Files
--
src/backend/commands/tsearchcmds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Use TSConfigRelationId in AlterTSConfiguration()

[Stephen Frost]

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 AlterTSConfiguration(), we're
saving information about the command via
EventTriggerCollectAlterTSConfig(), so we should be setting
commandCollected to true.  Also add a regression test to
test_ddl_deparse for ALTER TEXT SEARCH CONFIGURATION.

Author: Artur Zakirov, a few additional comments by me
Discussion: 
https://www.postgresql.org/message-id/57a71eba-f2c7-e7fd-6fc0-2126ec0b39bd%40postgrespro.ru

Back-patch the fix for the InvokeObjectPostAlterHook() call to 9.3 where
it was introduced, and the fix for the ObjectAddressSet() call and
setting commandCollected to true to 9.5 where those changes to
ProcessUtilitySlow() were introduced.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/12bd7dd317e8f4346fb3507578aca790ede6ebea

Modified Files
--
src/backend/commands/tsearchcmds.c | 4 ++--
src/backend/tcop/utility.c | 8 +++-
src/test/modules/test_ddl_deparse/Makefile | 1 +
src/test/modules/test_ddl_deparse/expected/alter_ts_config.out | 8 
src/test/modules/test_ddl_deparse/sql/alter_ts_config.sql  | 8 
5 files changed, 26 insertions(+), 3 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Improve ALTER TABLE documentation

[Stephen Frost]

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 not when multiple tables
are being moved with ALL IN TABLESPACE.  Further, the actions are
applied together but not really in 'parallel', at least today.

Pointed out by: Amit Langote

Improved wording from Tom.

Back-patch to 9.4, where the ALL IN TABLESPACE option was added.

Discussion: 
https://www.postgresql.org/message-id/14c535b4-13ef-0590-1b98-76af355a0763%40lab.ntt.co.jp

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/2d1018ca56f5ddaf0bfb5b4d0133283f3e823301

Modified Files
--
doc/src/sgml/ref/alter_table.sgml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Improve ALTER TABLE documentation

[Stephen Frost]

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 not when multiple tables
are being moved with ALL IN TABLESPACE.  Further, the actions are
applied together but not really in 'parallel', at least today.

Pointed out by: Amit Langote

Improved wording from Tom.

Back-patch to 9.4, where the ALL IN TABLESPACE option was added.

Discussion: 
https://www.postgresql.org/message-id/14c535b4-13ef-0590-1b98-76af355a0763%40lab.ntt.co.jp

Branch
--
REL9_5_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/ec2bc3264ef007e6d7b6463029de689273161336

Modified Files
--
doc/src/sgml/ref/alter_table.sgml | 8 
1 file changed, 4 insertions(+), 4 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Improve ALTER TABLE documentation

[Stephen Frost]

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 not when multiple tables
are being moved with ALL IN TABLESPACE.  Further, the actions are
applied together but not really in 'parallel', at least today.

Pointed out by: Amit Langote

Improved wording from Tom.

Back-patch to 9.4, where the ALL IN TABLESPACE option was added.

Discussion: 
https://www.postgresql.org/message-id/14c535b4-13ef-0590-1b98-76af355a0763%40lab.ntt.co.jp

Branch
--
REL9_4_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/b5fe1d4cd93d281eef7ab6718716d169609b000a

Modified Files
--
doc/src/sgml/ref/alter_table.sgml | 8 
1 file changed, 4 insertions(+), 4 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers