[COMMITTERS] pgsql: Doc: improve link.

2016-11-10 Thread Tom Lane
Doc: improve link.

Discussion: <[email protected]>

Branch
--
master

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

Modified Files
--
doc/src/sgml/storage.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


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


[COMMITTERS] pgsql: Fix partial aggregation for the case of a degenerate GROUP BY cl

2016-11-10 Thread Tom Lane
Fix partial aggregation for the case of a degenerate GROUP BY clause.

The plan generated for sorted partial aggregation with "GROUP BY constant"
included a Sort node with no sort keys, which the executor does not like.

Per report from Steve Randall.  I'd add a regression test case if I could
think of a compact one, but it doesn't seem worth expending lots of cycles
on.

Report: 

Branch
--
REL9_6_STABLE

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

Modified Files
--
src/backend/optimizer/plan/planner.c | 8 
1 file changed, 4 insertions(+), 4 deletions(-)


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


[COMMITTERS] pgsql: Fix partial aggregation for the case of a degenerate GROUP BY cl

2016-11-10 Thread Tom Lane
Fix partial aggregation for the case of a degenerate GROUP BY clause.

The plan generated for sorted partial aggregation with "GROUP BY constant"
included a Sort node with no sort keys, which the executor does not like.

Per report from Steve Randall.  I'd add a regression test case if I could
think of a compact one, but it doesn't seem worth expending lots of cycles
on.

Report: 

Branch
--
master

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

Modified Files
--
src/backend/optimizer/plan/planner.c | 8 
1 file changed, 4 insertions(+), 4 deletions(-)


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


[COMMITTERS] pgsql: Support "COPY view FROM" for views with INSTEAD OF INSERT trigge

2016-11-10 Thread Tom Lane
Support "COPY view FROM" for views with INSTEAD OF INSERT triggers.

We just pass the data to the INSTEAD trigger.

Haribabu Kommi, reviewed by Dilip Kumar

Patch: 

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/279c439c7fbc1bcb52173d92dd3b1fbe63e497ab

Modified Files
--
doc/src/sgml/ref/copy.sgml  |  10 +++-
src/backend/commands/copy.c | 104 +---
src/test/regress/expected/copy2.out |  26 +
src/test/regress/sql/copy2.sql  |  29 ++
4 files changed, 125 insertions(+), 44 deletions(-)


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


[COMMITTERS] pgsql: Re-allow user_catalog_table option for materialized views.

2016-11-10 Thread Tom Lane
Re-allow user_catalog_table option for materialized views.

The reloptions stuff allows this option to be set on a matview.
While it's questionable whether that is useful or was really intended,
it does work, and we shouldn't change that in minor releases.  Commit
e3e66d8a9 disabled the option since I didn't realize that it was
possible for it to be set on a matview.  Tweak the test to re-allow it.

Discussion: <[email protected]>

Branch
--
REL9_5_STABLE

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

Modified Files
--
src/include/utils/rel.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)


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


[COMMITTERS] pgsql: Re-allow user_catalog_table option for materialized views.

2016-11-10 Thread Tom Lane
Re-allow user_catalog_table option for materialized views.

The reloptions stuff allows this option to be set on a matview.
While it's questionable whether that is useful or was really intended,
it does work, and we shouldn't change that in minor releases.  Commit
e3e66d8a9 disabled the option since I didn't realize that it was
possible for it to be set on a matview.  Tweak the test to re-allow it.

Discussion: <[email protected]>

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/05a6e872898acad6a66f9fd0be01e30ae1fb0f75

Modified Files
--
src/include/utils/rel.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)


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


[COMMITTERS] pgsql: Re-allow user_catalog_table option for materialized views.

2016-11-10 Thread Tom Lane
Re-allow user_catalog_table option for materialized views.

The reloptions stuff allows this option to be set on a matview.
While it's questionable whether that is useful or was really intended,
it does work, and we shouldn't change that in minor releases.  Commit
e3e66d8a9 disabled the option since I didn't realize that it was
possible for it to be set on a matview.  Tweak the test to re-allow it.

Discussion: <[email protected]>

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/530f8065243b185e56c70ab317a9b40964b4ad00

Modified Files
--
src/include/utils/rel.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)


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


[COMMITTERS] pgsql: Cleanup of rewriter and planner handling of Query.hasRowSecurity

2016-11-10 Thread Tom Lane
Cleanup of rewriter and planner handling of Query.hasRowSecurity flag.

Be sure to pull up the subquery's hasRowSecurity flag when flattening a
subquery in pull_up_simple_subquery().  This isn't a bug today because
we don't look at the hasRowSecurity flag during planning, but it could
easily be a bug tomorrow.

Likewise, make rewriteRuleAction() pull up the hasRowSecurity flag when
absorbing RTEs from a rule action.  This isn't a bug either, for the
opposite reason: the flag should never be set yet.  But again, it seems
like good future proofing.

Add a comment explaining why rewriteTargetView() should *not* set
hasRowSecurity when adding stuff to securityQuals.

Improve some nearby comments about securityQuals processing, and document
that field more completely in parsenodes.h.

Patch by me, analysis by Dean Rasheed.

Discussion: 

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/24aef33804be5d7d71bc3932ced3407fce71e354

Modified Files
--
src/backend/optimizer/prep/prepjointree.c |  3 +++
src/backend/rewrite/rewriteHandler.c  | 32 ---
src/include/nodes/parsenodes.h|  9 -
3 files changed, 36 insertions(+), 8 deletions(-)


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