[COMMITTERS] pgsql: Further fix for psql's code for locale-aware formatting of numer

[Tom Lane]

Further fix for psql's code for locale-aware formatting of numeric output.

On closer inspection, those seemingly redundant atoi() calls were not so
much inefficient as just plain wrong: the author of this code either had
not read, or had not understood, the POSIX specification for localeconv().
The grouping field is *not* a textual digit string but separate integers
encoded as chars.

We'll follow the existing code as well as the backend's cash.c in only
honoring the first group width, but let's at least honor it correctly.

This doesn't actually result in any behavioral change in any of the
locales I have installed on my Linux box, which may explain why nobody's
complained; grouping width 3 is close enough to universal that it's barely
worth considering other cases.  Still, wrong is wrong, so back-patch.

Branch
--
REL9_0_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/71763ecff64cecc78384ef44c720f6e95db05f31

Modified Files
--
src/bin/psql/print.c |   14 +++---
1 file changed, 11 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: Further fix for psql's code for locale-aware formatting of numer

[Tom Lane]

Further fix for psql's code for locale-aware formatting of numeric output.

On closer inspection, those seemingly redundant atoi() calls were not so
much inefficient as just plain wrong: the author of this code either had
not read, or had not understood, the POSIX specification for localeconv().
The grouping field is *not* a textual digit string but separate integers
encoded as chars.

We'll follow the existing code as well as the backend's cash.c in only
honoring the first group width, but let's at least honor it correctly.

This doesn't actually result in any behavioral change in any of the
locales I have installed on my Linux box, which may explain why nobody's
complained; grouping width 3 is close enough to universal that it's barely
worth considering other cases.  Still, wrong is wrong, so back-patch.

Branch
--
REL9_3_STABLE

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

Modified Files
--
src/bin/psql/print.c |   14 +++---
1 file changed, 11 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: Further fix for psql's code for locale-aware formatting of numer

[Tom Lane]

Further fix for psql's code for locale-aware formatting of numeric output.

On closer inspection, those seemingly redundant atoi() calls were not so
much inefficient as just plain wrong: the author of this code either had
not read, or had not understood, the POSIX specification for localeconv().
The grouping field is *not* a textual digit string but separate integers
encoded as chars.

We'll follow the existing code as well as the backend's cash.c in only
honoring the first group width, but let's at least honor it correctly.

This doesn't actually result in any behavioral change in any of the
locales I have installed on my Linux box, which may explain why nobody's
complained; grouping width 3 is close enough to universal that it's barely
worth considering other cases.  Still, wrong is wrong, so back-patch.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/6325527d845b629243fb3f605af6747a7a4ac45f

Modified Files
--
src/bin/psql/print.c |   14 +++---
1 file changed, 11 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: Further fix for psql's code for locale-aware formatting of numer

[Tom Lane]

Further fix for psql's code for locale-aware formatting of numeric output.

On closer inspection, those seemingly redundant atoi() calls were not so
much inefficient as just plain wrong: the author of this code either had
not read, or had not understood, the POSIX specification for localeconv().
The grouping field is *not* a textual digit string but separate integers
encoded as chars.

We'll follow the existing code as well as the backend's cash.c in only
honoring the first group width, but let's at least honor it correctly.

This doesn't actually result in any behavioral change in any of the
locales I have installed on my Linux box, which may explain why nobody's
complained; grouping width 3 is close enough to universal that it's barely
worth considering other cases.  Still, wrong is wrong, so back-patch.

Branch
--
REL9_2_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/60617d7d680e46e45126baa98c6e20728300c893

Modified Files
--
src/bin/psql/print.c |   14 +++---
1 file changed, 11 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: Further fix for psql's code for locale-aware formatting of numer

[Tom Lane]

Further fix for psql's code for locale-aware formatting of numeric output.

On closer inspection, those seemingly redundant atoi() calls were not so
much inefficient as just plain wrong: the author of this code either had
not read, or had not understood, the POSIX specification for localeconv().
The grouping field is *not* a textual digit string but separate integers
encoded as chars.

We'll follow the existing code as well as the backend's cash.c in only
honoring the first group width, but let's at least honor it correctly.

This doesn't actually result in any behavioral change in any of the
locales I have installed on my Linux box, which may explain why nobody's
complained; grouping width 3 is close enough to universal that it's barely
worth considering other cases.  Still, wrong is wrong, so back-patch.

Branch
--
REL9_1_STABLE

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

Modified Files
--
src/bin/psql/print.c |   14 +++---
1 file changed, 11 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: Further fix for psql's code for locale-aware formatting of numer

[Tom Lane]

Further fix for psql's code for locale-aware formatting of numeric output.

On closer inspection, those seemingly redundant atoi() calls were not so
much inefficient as just plain wrong: the author of this code either had
not read, or had not understood, the POSIX specification for localeconv().
The grouping field is *not* a textual digit string but separate integers
encoded as chars.

We'll follow the existing code as well as the backend's cash.c in only
honoring the first group width, but let's at least honor it correctly.

This doesn't actually result in any behavioral change in any of the
locales I have installed on my Linux box, which may explain why nobody's
complained; grouping width 3 is close enough to universal that it's barely
worth considering other cases.  Still, wrong is wrong, so back-patch.

Branch
--
REL9_5_STABLE

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

Modified Files
--
src/bin/psql/print.c |   14 +++---
1 file changed, 11 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: Further fix for psql's code for locale-aware formatting of numer

[Tom Lane]

Further fix for psql's code for locale-aware formatting of numeric output.

On closer inspection, those seemingly redundant atoi() calls were not so
much inefficient as just plain wrong: the author of this code either had
not read, or had not understood, the POSIX specification for localeconv().
The grouping field is *not* a textual digit string but separate integers
encoded as chars.

We'll follow the existing code as well as the backend's cash.c in only
honoring the first group width, but let's at least honor it correctly.

This doesn't actually result in any behavioral change in any of the
locales I have installed on my Linux box, which may explain why nobody's
complained; grouping width 3 is close enough to universal that it's barely
worth considering other cases.  Still, wrong is wrong, so back-patch.

Branch
--
REL9_4_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/49917edadf9d787efbd71b7e1e689eb48c2a1c47

Modified Files
--
src/bin/psql/print.c |   14 +++---
1 file changed, 11 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: Fix psql's code for locale-aware formatting of numeric output.

[Tom Lane]

Fix psql's code for locale-aware formatting of numeric output.

This code did the wrong thing entirely for numbers with an exponent
but no decimal point (e.g., '1e6'), as reported by Jeff Janes in
bug #13636.  More generally, it made lots of unverified assumptions
about what the input string could possibly look like.  Rearrange so
that it only fools with leading digits that it's directly verified
are there, and an immediately adjacent decimal point.  While at it,
get rid of some useless inefficiencies, like converting the grouping
count string to integer over and over (and over).

This has been broken for a long time, so back-patch to all supported
branches.

Branch
--
REL9_4_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/348dd2847fa4a379e452ee00ab2016ec1629202d

Modified Files
--
src/bin/psql/print.c |  103 +++---
1 file changed, 47 insertions(+), 56 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 psql's code for locale-aware formatting of numeric output.

[Tom Lane]

Fix psql's code for locale-aware formatting of numeric output.

This code did the wrong thing entirely for numbers with an exponent
but no decimal point (e.g., '1e6'), as reported by Jeff Janes in
bug #13636.  More generally, it made lots of unverified assumptions
about what the input string could possibly look like.  Rearrange so
that it only fools with leading digits that it's directly verified
are there, and an immediately adjacent decimal point.  While at it,
get rid of some useless inefficiencies, like converting the grouping
count string to integer over and over (and over).

This has been broken for a long time, so back-patch to all supported
branches.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/4778a0bdaac3cb8eeb89acb585fd913783d80c4b

Modified Files
--
src/bin/psql/print.c |  103 +++---
1 file changed, 47 insertions(+), 56 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 psql's code for locale-aware formatting of numeric output.

[Tom Lane]

Fix psql's code for locale-aware formatting of numeric output.

This code did the wrong thing entirely for numbers with an exponent
but no decimal point (e.g., '1e6'), as reported by Jeff Janes in
bug #13636.  More generally, it made lots of unverified assumptions
about what the input string could possibly look like.  Rearrange so
that it only fools with leading digits that it's directly verified
are there, and an immediately adjacent decimal point.  While at it,
get rid of some useless inefficiencies, like converting the grouping
count string to integer over and over (and over).

This has been broken for a long time, so back-patch to all supported
branches.

Branch
--
REL9_5_STABLE

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

Modified Files
--
src/bin/psql/print.c |  103 +++---
1 file changed, 47 insertions(+), 56 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 psql's code for locale-aware formatting of numeric output.

[Tom Lane]

Fix psql's code for locale-aware formatting of numeric output.

This code did the wrong thing entirely for numbers with an exponent
but no decimal point (e.g., '1e6'), as reported by Jeff Janes in
bug #13636.  More generally, it made lots of unverified assumptions
about what the input string could possibly look like.  Rearrange so
that it only fools with leading digits that it's directly verified
are there, and an immediately adjacent decimal point.  While at it,
get rid of some useless inefficiencies, like converting the grouping
count string to integer over and over (and over).

This has been broken for a long time, so back-patch to all supported
branches.

Branch
--
REL9_1_STABLE

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

Modified Files
--
src/bin/psql/print.c |  103 ++
1 file changed, 45 insertions(+), 58 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 psql's code for locale-aware formatting of numeric output.

[Tom Lane]

Fix psql's code for locale-aware formatting of numeric output.

This code did the wrong thing entirely for numbers with an exponent
but no decimal point (e.g., '1e6'), as reported by Jeff Janes in
bug #13636.  More generally, it made lots of unverified assumptions
about what the input string could possibly look like.  Rearrange so
that it only fools with leading digits that it's directly verified
are there, and an immediately adjacent decimal point.  While at it,
get rid of some useless inefficiencies, like converting the grouping
count string to integer over and over (and over).

This has been broken for a long time, so back-patch to all supported
branches.

Branch
--
REL9_3_STABLE

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

Modified Files
--
src/bin/psql/print.c |  102 ++
1 file changed, 45 insertions(+), 57 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 psql's code for locale-aware formatting of numeric output.

[Tom Lane]

Fix psql's code for locale-aware formatting of numeric output.

This code did the wrong thing entirely for numbers with an exponent
but no decimal point (e.g., '1e6'), as reported by Jeff Janes in
bug #13636.  More generally, it made lots of unverified assumptions
about what the input string could possibly look like.  Rearrange so
that it only fools with leading digits that it's directly verified
are there, and an immediately adjacent decimal point.  While at it,
get rid of some useless inefficiencies, like converting the grouping
count string to integer over and over (and over).

This has been broken for a long time, so back-patch to all supported
branches.

Branch
--
REL9_0_STABLE

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

Modified Files
--
src/bin/psql/print.c |  103 ++
1 file changed, 45 insertions(+), 58 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 psql's code for locale-aware formatting of numeric output.

[Tom Lane]

Fix psql's code for locale-aware formatting of numeric output.

This code did the wrong thing entirely for numbers with an exponent
but no decimal point (e.g., '1e6'), as reported by Jeff Janes in
bug #13636.  More generally, it made lots of unverified assumptions
about what the input string could possibly look like.  Rearrange so
that it only fools with leading digits that it's directly verified
are there, and an immediately adjacent decimal point.  While at it,
get rid of some useless inefficiencies, like converting the grouping
count string to integer over and over (and over).

This has been broken for a long time, so back-patch to all supported
branches.

Branch
--
REL9_2_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/596c9e9efdbef0b0a597f3c8df478e51a50729e3

Modified Files
--
src/bin/psql/print.c |  103 ++
1 file changed, 45 insertions(+), 58 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: Allow planner to use expression-index stats for function calls i

[Tom Lane]

Allow planner to use expression-index stats for function calls in WHERE.

Previously, a function call appearing at the top level of WHERE had a
hard-wired selectivity estimate of 0.333, a kludge conveniently dated
in the source code itself to July 1992.  The expectation at the time was
that somebody would soon implement estimator support functions analogous
to those for operators; but no such code has appeared, nor does it seem
likely to in the near future.  We do have an alternative solution though,
at least for immutable functions on single relations: creating an
expression index on the function call will allow ANALYZE to gather stats
about the function's selectivity.  But the code in clause_selectivity()
failed to make use of such data even if it exists.

Refactor so that that will happen.  I chose to make it try this technique
for any clause type for which clause_selectivity() doesn't have a special
case, not just functions.  To avoid adding unnecessary overhead in the
common case where we don't learn anything new, make selfuncs.c provide an
API that hooks directly to examine_variable() and then var_eq_const(),
rather than the previous coding which laboriously constructed an OpExpr
only so that it could be expensively deconstructed again.

I preserved the behavior that the default estimate for a function call
is 0.333.  (For any other expression node type, it's 0.5, as before.)
I had originally thought to make the default be 0.5 across the board, but
changing a default estimate that's survived for twenty-three years seems
like something not to do without a lot more testing than I care to put
into it right now.

Per a complaint from Jehan-Guillaume de Rorthais.  Back-patch into 9.5,
but not further, at least for the moment.

Branch
--
REL9_5_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/45d256c2792e20c52235470e62a70c9c80a96274

Modified Files
--
src/backend/optimizer/path/clausesel.c |   45 +---
src/backend/utils/adt/selfuncs.c   |   45 
src/include/utils/selfuncs.h   |1 +
3 files changed, 59 insertions(+), 32 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: Allow planner to use expression-index stats for function calls i

[Tom Lane]

Allow planner to use expression-index stats for function calls in WHERE.

Previously, a function call appearing at the top level of WHERE had a
hard-wired selectivity estimate of 0.333, a kludge conveniently dated
in the source code itself to July 1992.  The expectation at the time was
that somebody would soon implement estimator support functions analogous
to those for operators; but no such code has appeared, nor does it seem
likely to in the near future.  We do have an alternative solution though,
at least for immutable functions on single relations: creating an
expression index on the function call will allow ANALYZE to gather stats
about the function's selectivity.  But the code in clause_selectivity()
failed to make use of such data even if it exists.

Refactor so that that will happen.  I chose to make it try this technique
for any clause type for which clause_selectivity() doesn't have a special
case, not just functions.  To avoid adding unnecessary overhead in the
common case where we don't learn anything new, make selfuncs.c provide an
API that hooks directly to examine_variable() and then var_eq_const(),
rather than the previous coding which laboriously constructed an OpExpr
only so that it could be expensively deconstructed again.

I preserved the behavior that the default estimate for a function call
is 0.333.  (For any other expression node type, it's 0.5, as before.)
I had originally thought to make the default be 0.5 across the board, but
changing a default estimate that's survived for twenty-three years seems
like something not to do without a lot more testing than I care to put
into it right now.

Per a complaint from Jehan-Guillaume de Rorthais.  Back-patch into 9.5,
but not further, at least for the moment.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/39df0f150ca69fac1c89537065ddc97af18921b8

Modified Files
--
src/backend/optimizer/path/clausesel.c |   45 +---
src/backend/utils/adt/selfuncs.c   |   45 
src/include/utils/selfuncs.h   |1 +
3 files changed, 59 insertions(+), 32 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: RLS refactoring

[Stephen Frost]

Tom, all,

* Tom Lane (t...@sss.pgh.pa.us) wrote:
> My vote would be to rename and reposition the field in HEAD and 9.5
> and accept the corresponding initdb.  We already forced an initdb
> since alpha2, so it's basically free as far as testers are concerned,
> and keeping 9.5 in sync with HEAD in this area seems like a really
> good idea for awhile to come.

Alright, attached is an attempt at doing these renames.  I went a bit
farther since it seemed to make sense to me (at least at the time, I'm
wondering a bit about it now), so, please provide any thoughts or
feedback you have regarding these changes.

Thanks!

Stephen
From 579dcfb80ffb922cabf10590219de221bb12267a Mon Sep 17 00:00:00 2001
From: Stephen Frost 
Date: Thu, 24 Sep 2015 10:21:42 -0400
Subject: [PATCH] Rename withCheckOptions to insertedCheckClauses

CHECK clauses which are generated from the WITH CHECK OPTION being
specified on a view or from RLS WITH CHECK policies are always inserted
by the rewriter and therefore don't ever need to be persisted out on
disk for a given query.

This modifies outfuncs to no longer output the rewriter-added nodes for
a Query or a ModifyTable, and readfuncs to no longer read them in.

Further, rename 'withCheckOptions' in Query and ModifyTable to
'insertedCheckClauses', ExecWithCheckOption to ExecCheckClauses,
ri_WithCheckOptions and ri_WithCheckOptionExprs to
ri_InsertedCheckClauses and ri_InsertedCheckExprs, respectively, all to
make it clear that these are the check clauses which were added by the
rewriter, not the actual WITH CHECK OPTION indication for a view (which
is stored in reloptions for the view) nor the WITH CHECK expressions for
a policy (which are stored in pg_policy).

Requires a catversion bump.

Per discussion with Tom and Alvaro.

Backpatch to 9.5 since we're still in alpha.
---
 src/backend/executor/execMain.c   | 16 +--
 src/backend/executor/nodeModifyTable.c| 45 +++
 src/backend/nodes/copyfuncs.c |  4 +--
 src/backend/nodes/equalfuncs.c|  2 +-
 src/backend/nodes/nodeFuncs.c |  4 +--
 src/backend/nodes/outfuncs.c  |  2 --
 src/backend/nodes/readfuncs.c | 21 ---
 src/backend/optimizer/plan/createplan.c   |  8 +++---
 src/backend/optimizer/plan/planner.c  | 42 +
 src/backend/optimizer/plan/setrefs.c  |  4 +--
 src/backend/optimizer/prep/prepsecurity.c |  2 +-
 src/backend/rewrite/rewriteHandler.c  | 37 -
 src/backend/rewrite/rowsecurity.c | 28 +--
 src/include/executor/executor.h   |  2 +-
 src/include/nodes/execnodes.h |  8 +++---
 src/include/nodes/parsenodes.h|  8 --
 src/include/nodes/plannodes.h |  2 +-
 src/include/optimizer/planmain.h  |  2 +-
 src/include/rewrite/rowsecurity.h |  2 +-
 19 files changed, 114 insertions(+), 125 deletions(-)

diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index 85ff46b..d344b09 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -1738,17 +1738,17 @@ ExecConstraints(ResultRelInfo *resultRelInfo,
 }
 
 /*
- * ExecWithCheckOptions -- check that tuple satisfies any WITH CHECK OPTIONs
+ * ExecCheckClauses -- check that tuple satisfies any inserted CHECK clauses,
  * of the specified kind.
  *
  * Note that this needs to be called multiple times to ensure that all kinds of
- * WITH CHECK OPTIONs are handled (both those from views which have the WITH
- * CHECK OPTION set and from row level security policies).  See ExecInsert()
- * and ExecUpdate().
+ * CHECK clauses are handled (both those from views which have the WITH CHECK
+ * OPTION set and from row level security policies).  See ExecInsert() and
+ * ExecUpdate().
  */
 void
-ExecWithCheckOptions(WCOKind kind, ResultRelInfo *resultRelInfo,
-	 TupleTableSlot *slot, EState *estate)
+ExecCheckClauses(WCOKind kind, ResultRelInfo *resultRelInfo,
+ TupleTableSlot *slot, EState *estate)
 {
 	Relation	rel = resultRelInfo->ri_RelationDesc;
 	TupleDesc	tupdesc = RelationGetDescr(rel);
@@ -1766,8 +1766,8 @@ ExecWithCheckOptions(WCOKind kind, ResultRelInfo *resultRelInfo,
 	econtext->ecxt_scantuple = slot;
 
 	/* Check each of the constraints */
-	forboth(l1, resultRelInfo->ri_WithCheckOptions,
-			l2, resultRelInfo->ri_WithCheckOptionExprs)
+	forboth(l1, resultRelInfo->ri_InsertedCheckClauses,
+			l2, resultRelInfo->ri_InsertedCheckClauseExprs)
 	{
 		WithCheckOption *wco = (WithCheckOption *) lfirst(l1);
 		ExprState  *wcoExpr = (ExprState *) lfirst(l2);
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor/nodeModifyTable.c
index 1ef76d0..a310299 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -321,12 +321,11 @@ ExecInsert(ModifyTableState *mtstate,
 		/*
 		 * Check any RLS INSERT WITH CHECK policies
 		

[COMMITTERS] pgsql: Improve handling of collations in contrib/postgres_fdw.

[Tom Lane]

Improve handling of collations in contrib/postgres_fdw.

If we have a local Var of say varchar type with default collation, and
we apply a RelabelType to convert that to text with default collation, we
don't want to consider that as creating an FDW_COLLATE_UNSAFE situation.
It should be okay to compare that to a remote Var, so long as the remote
Var determines the comparison collation.  (When we actually ship such an
expression to the remote side, the local Var would become a Param with
default collation, meaning the remote Var would in fact control the
comparison collation, because non-default implicit collation overrides
default implicit collation in parse_collate.c.)  To fix, be more precise
about what FDW_COLLATE_NONE means: it applies either to a noncollatable
data type or to a collatable type with default collation, if that collation
can't be traced to a remote Var.  (When it can, FDW_COLLATE_SAFE is
appropriate.)  We were essentially using that interpretation already at
the Var/Const/Param level, but we weren't bubbling it up properly.

An alternative fix would be to introduce a separate FDW_COLLATE_DEFAULT
value to describe the second situation, but that would add more code
without changing the actual behavior, so it didn't seem worthwhile.

Also, since we're clarifying the rule to be that we care about whether
operator/function input collations match, there seems no need to fail
immediately upon seeing a Const/Param/non-foreign-Var with nondefault
collation.  We only have to reject if it appears in a collation-sensitive
context (for example, "var IS NOT NULL" is perfectly safe from a collation
standpoint, whatever collation the var has).  So just set the state to
UNSAFE rather than failing immediately.

Per report from Jeevan Chalke.  This essentially corrects some sloppy
thinking in commit ed3ddf918b59545583a4b374566bc1148e75f593, so back-patch
to 9.3 where that logic appeared.

Branch
--
REL9_5_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/59d765b6554093701329be935b52d82d9af01401

Modified Files
--
contrib/postgres_fdw/deparse.c |   89 +
contrib/postgres_fdw/expected/postgres_fdw.out |  101 
contrib/postgres_fdw/sql/postgres_fdw.sql  |   11 ++-
3 files changed, 135 insertions(+), 66 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 handling of collations in contrib/postgres_fdw.

[Tom Lane]

Improve handling of collations in contrib/postgres_fdw.

If we have a local Var of say varchar type with default collation, and
we apply a RelabelType to convert that to text with default collation, we
don't want to consider that as creating an FDW_COLLATE_UNSAFE situation.
It should be okay to compare that to a remote Var, so long as the remote
Var determines the comparison collation.  (When we actually ship such an
expression to the remote side, the local Var would become a Param with
default collation, meaning the remote Var would in fact control the
comparison collation, because non-default implicit collation overrides
default implicit collation in parse_collate.c.)  To fix, be more precise
about what FDW_COLLATE_NONE means: it applies either to a noncollatable
data type or to a collatable type with default collation, if that collation
can't be traced to a remote Var.  (When it can, FDW_COLLATE_SAFE is
appropriate.)  We were essentially using that interpretation already at
the Var/Const/Param level, but we weren't bubbling it up properly.

An alternative fix would be to introduce a separate FDW_COLLATE_DEFAULT
value to describe the second situation, but that would add more code
without changing the actual behavior, so it didn't seem worthwhile.

Also, since we're clarifying the rule to be that we care about whether
operator/function input collations match, there seems no need to fail
immediately upon seeing a Const/Param/non-foreign-Var with nondefault
collation.  We only have to reject if it appears in a collation-sensitive
context (for example, "var IS NOT NULL" is perfectly safe from a collation
standpoint, whatever collation the var has).  So just set the state to
UNSAFE rather than failing immediately.

Per report from Jeevan Chalke.  This essentially corrects some sloppy
thinking in commit ed3ddf918b59545583a4b374566bc1148e75f593, so back-patch
to 9.3 where that logic appeared.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/76f965ff1f2896d74812a1cad9158fb9f4a1aab9

Modified Files
--
contrib/postgres_fdw/deparse.c |   89 +
contrib/postgres_fdw/expected/postgres_fdw.out |  101 
contrib/postgres_fdw/sql/postgres_fdw.sql  |   11 ++-
3 files changed, 135 insertions(+), 66 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 handling of collations in contrib/postgres_fdw.

[Tom Lane]

Improve handling of collations in contrib/postgres_fdw.

If we have a local Var of say varchar type with default collation, and
we apply a RelabelType to convert that to text with default collation, we
don't want to consider that as creating an FDW_COLLATE_UNSAFE situation.
It should be okay to compare that to a remote Var, so long as the remote
Var determines the comparison collation.  (When we actually ship such an
expression to the remote side, the local Var would become a Param with
default collation, meaning the remote Var would in fact control the
comparison collation, because non-default implicit collation overrides
default implicit collation in parse_collate.c.)  To fix, be more precise
about what FDW_COLLATE_NONE means: it applies either to a noncollatable
data type or to a collatable type with default collation, if that collation
can't be traced to a remote Var.  (When it can, FDW_COLLATE_SAFE is
appropriate.)  We were essentially using that interpretation already at
the Var/Const/Param level, but we weren't bubbling it up properly.

An alternative fix would be to introduce a separate FDW_COLLATE_DEFAULT
value to describe the second situation, but that would add more code
without changing the actual behavior, so it didn't seem worthwhile.

Also, since we're clarifying the rule to be that we care about whether
operator/function input collations match, there seems no need to fail
immediately upon seeing a Const/Param/non-foreign-Var with nondefault
collation.  We only have to reject if it appears in a collation-sensitive
context (for example, "var IS NOT NULL" is perfectly safe from a collation
standpoint, whatever collation the var has).  So just set the state to
UNSAFE rather than failing immediately.

Per report from Jeevan Chalke.  This essentially corrects some sloppy
thinking in commit ed3ddf918b59545583a4b374566bc1148e75f593, so back-patch
to 9.3 where that logic appeared.

Branch
--
REL9_3_STABLE

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

Modified Files
--
contrib/postgres_fdw/deparse.c |   89 +
contrib/postgres_fdw/expected/postgres_fdw.out |  101 
contrib/postgres_fdw/sql/postgres_fdw.sql  |   11 ++-
3 files changed, 135 insertions(+), 66 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 handling of collations in contrib/postgres_fdw.

[Tom Lane]

Improve handling of collations in contrib/postgres_fdw.

If we have a local Var of say varchar type with default collation, and
we apply a RelabelType to convert that to text with default collation, we
don't want to consider that as creating an FDW_COLLATE_UNSAFE situation.
It should be okay to compare that to a remote Var, so long as the remote
Var determines the comparison collation.  (When we actually ship such an
expression to the remote side, the local Var would become a Param with
default collation, meaning the remote Var would in fact control the
comparison collation, because non-default implicit collation overrides
default implicit collation in parse_collate.c.)  To fix, be more precise
about what FDW_COLLATE_NONE means: it applies either to a noncollatable
data type or to a collatable type with default collation, if that collation
can't be traced to a remote Var.  (When it can, FDW_COLLATE_SAFE is
appropriate.)  We were essentially using that interpretation already at
the Var/Const/Param level, but we weren't bubbling it up properly.

An alternative fix would be to introduce a separate FDW_COLLATE_DEFAULT
value to describe the second situation, but that would add more code
without changing the actual behavior, so it didn't seem worthwhile.

Also, since we're clarifying the rule to be that we care about whether
operator/function input collations match, there seems no need to fail
immediately upon seeing a Const/Param/non-foreign-Var with nondefault
collation.  We only have to reject if it appears in a collation-sensitive
context (for example, "var IS NOT NULL" is perfectly safe from a collation
standpoint, whatever collation the var has).  So just set the state to
UNSAFE rather than failing immediately.

Per report from Jeevan Chalke.  This essentially corrects some sloppy
thinking in commit ed3ddf918b59545583a4b374566bc1148e75f593, so back-patch
to 9.3 where that logic appeared.

Branch
--
REL9_4_STABLE

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

Modified Files
--
contrib/postgres_fdw/deparse.c |   89 +
contrib/postgres_fdw/expected/postgres_fdw.out |  101 
contrib/postgres_fdw/sql/postgres_fdw.sql  |   11 ++-
3 files changed, 135 insertions(+), 66 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: Don't zero opfuncid when reading nodes.

[Robert Haas]

Don't zero opfuncid when reading nodes.

The comments here stated that this was just in case we ever had an
ALTER OPERATOR command that could remap an operator to a different
function.  But those comments have been here for a long time, and no
such command has come about.  In the absence of such a feature,
forcing the pg_proc OID to be looked up again each time we reread a
stored rule or similar is just a waste of cycles.  Moreover, parallel
query needs a way to reread the exact same node tree that was written
out, not one that has been slightly stomped on.  So just get rid of
this for now.

Per discussion with Tom Lane.

Branch
--
master

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

Modified Files
--
src/backend/nodes/readfuncs.c |   44 -
1 file changed, 44 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: Lower *_freeze_max_age minimum values.

[Andres Freund]

On 2015-09-24 10:37:33 -0400, Tom Lane wrote:
> Andres Freund  writes:
> > Lower *_freeze_max_age minimum values.
> 
> Should this patch not have also touched the per-table limits in
> reloptions.c?

Hm. I guess that'd make sense. It's not really related to the goal of
making it realistic to test multixact/clog truncation, but it's less
confusing if consistent.

> Also, I went looking for documentation about the minimum allowed
> values,

I seached for references and was surprised we don't document the limits
anywhere

> and I found places in create_table.sgml that claim these variables can be
> set to zero.  You didn't break that with this patch, but it's still wrong.

Seems to have been "broken" back in 834a6da4f7 - the old table based
approach doesn't seem to have imposed lower limits. I'm not really sure
whether making the limits consistent and updating the docs or removing
them alltogether is the better approach.

Greetings,

Andres Freund


-- 
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: Lower *_freeze_max_age minimum values.

[Tom Lane]

Andres Freund  writes:
> Lower *_freeze_max_age minimum values.

Should this patch not have also touched the per-table limits in
reloptions.c?

Also, I went looking for documentation about the minimum allowed values,
and I found places in create_table.sgml that claim these variables can be
set to zero.  You didn't break that with this patch, but it's still wrong.

regards, tom lane


-- 
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: Make pg_controldata report newest XID with valid commit timestam

[Fujii Masao]

Make pg_controldata report newest XID with valid commit timestamp

Previously pg_controldata didn't report newestCommitTs and this was
an oversight in commit 73c986a.

Also this patch changes pg_resetxlog so that it uses the same sentences
as pg_controldata does, regarding oldestCommitTs and newestCommitTs,
for the sake of consistency.

Back-patch to 9.5 where track_commit_timestamp was added.

Euler Taveira

Branch
--
REL9_5_STABLE

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

Modified Files
--
src/bin/pg_controldata/pg_controldata.c |2 ++
src/bin/pg_resetxlog/pg_resetxlog.c |4 ++--
2 files changed, 4 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: Make pg_controldata report newest XID with valid commit timestam

[Fujii Masao]

Make pg_controldata report newest XID with valid commit timestamp

Previously pg_controldata didn't report newestCommitTs and this was
an oversight in commit 73c986a.

Also this patch changes pg_resetxlog so that it uses the same sentences
as pg_controldata does, regarding oldestCommitTs and newestCommitTs,
for the sake of consistency.

Back-patch to 9.5 where track_commit_timestamp was added.

Euler Taveira

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/18d938de7a99d698d33cc3a94507c8fe0a0005ab

Modified Files
--
src/bin/pg_controldata/pg_controldata.c |2 ++
src/bin/pg_resetxlog/pg_resetxlog.c |4 ++--
2 files changed, 4 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: Lower *_freeze_max_age minimum values.

[Andres Freund]

Lower *_freeze_max_age minimum values.

The old minimum values are rather large, making it time consuming to
test related behaviour. Additionally the current limits, especially for
multixacts, can be problematic in space-constrained systems. 1000
multixacts can contain a lot of members.

Since there's no good reason for the current limits, lower them a good
bit. Setting them to 0 would be a bad idea, triggering endless vacuums,
so still retain a limit.

While at it fix autovacuum_multixact_freeze_max_age to refer to
multixact.c instead of varsup.c.

Reviewed-By: Robert Haas
Discussion: CA+TgmoYmQPHcrc3GSs7vwvrbTkbcGD9Gik=oztbdggrovkk...@mail.gmail.com
Backpatch: 9.0 (in parts)

Branch
--
REL9_0_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/078d471a909a07bc7dc93def37b6811e236f8a84

Modified Files
--
src/backend/utils/misc/guc.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: Lower *_freeze_max_age minimum values.

[Andres Freund]

Lower *_freeze_max_age minimum values.

The old minimum values are rather large, making it time consuming to
test related behaviour. Additionally the current limits, especially for
multixacts, can be problematic in space-constrained systems. 1000
multixacts can contain a lot of members.

Since there's no good reason for the current limits, lower them a good
bit. Setting them to 0 would be a bad idea, triggering endless vacuums,
so still retain a limit.

While at it fix autovacuum_multixact_freeze_max_age to refer to
multixact.c instead of varsup.c.

Reviewed-By: Robert Haas
Discussion: CA+TgmoYmQPHcrc3GSs7vwvrbTkbcGD9Gik=oztbdggrovkk...@mail.gmail.com
Backpatch: back to 9.0 (in parts)

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/020235a5754be6ba1f0d240b4c86c642e1a62d70

Modified Files
--
src/backend/utils/misc/guc.c |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: Lower *_freeze_max_age minimum values.

[Andres Freund]

Lower *_freeze_max_age minimum values.

The old minimum values are rather large, making it time consuming to
test related behaviour. Additionally the current limits, especially for
multixacts, can be problematic in space-constrained systems. 1000
multixacts can contain a lot of members.

Since there's no good reason for the current limits, lower them a good
bit. Setting them to 0 would be a bad idea, triggering endless vacuums,
so still retain a limit.

While at it fix autovacuum_multixact_freeze_max_age to refer to
multixact.c instead of varsup.c.

Reviewed-By: Robert Haas
Discussion: CA+TgmoYmQPHcrc3GSs7vwvrbTkbcGD9Gik=oztbdggrovkk...@mail.gmail.com
Backpatch: back to 9.0 (in parts)

Branch
--
REL9_4_STABLE

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

Modified Files
--
src/backend/utils/misc/guc.c |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: Lower *_freeze_max_age minimum values.

[Andres Freund]

Lower *_freeze_max_age minimum values.

The old minimum values are rather large, making it time consuming to
test related behaviour. Additionally the current limits, especially for
multixacts, can be problematic in space-constrained systems. 1000
multixacts can contain a lot of members.

Since there's no good reason for the current limits, lower them a good
bit. Setting them to 0 would be a bad idea, triggering endless vacuums,
so still retain a limit.

While at it fix autovacuum_multixact_freeze_max_age to refer to
multixact.c instead of varsup.c.

Reviewed-By: Robert Haas
Discussion: CA+TgmoYmQPHcrc3GSs7vwvrbTkbcGD9Gik=oztbdggrovkk...@mail.gmail.com
Backpatch: back to 9.0 (in parts)

Branch
--
REL9_3_STABLE

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

Modified Files
--
src/backend/utils/misc/guc.c |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: Lower *_freeze_max_age minimum values.

[Andres Freund]

Lower *_freeze_max_age minimum values.

The old minimum values are rather large, making it time consuming to
test related behaviour. Additionally the current limits, especially for
multixacts, can be problematic in space-constrained systems. 1000
multixacts can contain a lot of members.

Since there's no good reason for the current limits, lower them a good
bit. Setting them to 0 would be a bad idea, triggering endless vacuums,
so still retain a limit.

While at it fix autovacuum_multixact_freeze_max_age to refer to
multixact.c instead of varsup.c.

Reviewed-By: Robert Haas
Discussion: CA+TgmoYmQPHcrc3GSs7vwvrbTkbcGD9Gik=oztbdggrovkk...@mail.gmail.com
Backpatch: 9.0 (in parts)

Branch
--
REL9_2_STABLE

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

Modified Files
--
src/backend/utils/misc/guc.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: Lower *_freeze_max_age minimum values.

[Andres Freund]

Lower *_freeze_max_age minimum values.

The old minimum values are rather large, making it time consuming to
test related behaviour. Additionally the current limits, especially for
multixacts, can be problematic in space-constrained systems. 1000
multixacts can contain a lot of members.

Since there's no good reason for the current limits, lower them a good
bit. Setting them to 0 would be a bad idea, triggering endless vacuums,
so still retain a limit.

While at it fix autovacuum_multixact_freeze_max_age to refer to
multixact.c instead of varsup.c.

Reviewed-By: Robert Haas
Discussion: CA+TgmoYmQPHcrc3GSs7vwvrbTkbcGD9Gik=oztbdggrovkk...@mail.gmail.com
Backpatch: back to 9.0 (in parts)

Branch
--
REL9_5_STABLE

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

Modified Files
--
src/backend/utils/misc/guc.c |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: Lower *_freeze_max_age minimum values.

[Andres Freund]

Lower *_freeze_max_age minimum values.

The old minimum values are rather large, making it time consuming to
test related behaviour. Additionally the current limits, especially for
multixacts, can be problematic in space-constrained systems. 1000
multixacts can contain a lot of members.

Since there's no good reason for the current limits, lower them a good
bit. Setting them to 0 would be a bad idea, triggering endless vacuums,
so still retain a limit.

While at it fix autovacuum_multixact_freeze_max_age to refer to
multixact.c instead of varsup.c.

Reviewed-By: Robert Haas
Discussion: CA+TgmoYmQPHcrc3GSs7vwvrbTkbcGD9Gik=oztbdggrovkk...@mail.gmail.com
Backpatch: 9.0 (in parts)

Branch
--
REL9_1_STABLE

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

Modified Files
--
src/backend/utils/misc/guc.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

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

[Gavin Flower]

On 24/09/15 22:41, Geoff Winkless wrote:
On 24 September 2015 at 11:33, Gavin Flower 
>wrote:


An example from a book on PostgreSQL server programming that I'm
working through (Note that it is obviously awkward to write with
gender pronouns when gender is irrelevant, note the "he she" in
one place and "he/she" in another!):

   "If the user is a superuser, then they have permission to see the
   full query. If the user is a regular user, they will only see the
   full query for their queries."

Can I quietly suggest "​Users with superuser pemissions can always see 
the full query​, while regular users will only see the full query for 
their own queries."?


Geoff

By all means say it quietly!  :-)

But I was simply trying to change it into Gender Appropriate form, 
rather improve it in other aspects.


However, your rephrasing is better still!


-Gavin


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

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

[Geoff Winkless]

On 24 September 2015 at 11:33, Gavin Flower 
wrote:

> An example from a book on PostgreSQL server programming that I'm working
> through (Note that it is obviously awkward to write with gender pronouns
> when gender is irrelevant, note the "he she" in one place and "he/she" in
> another!):
>
>"If the user is a superuser, then they have permission to see the
>full query. If the user is a regular user, they will only see the
>full query for their queries."
>

Can I quietly suggest "​Users with superuser pemissions can always see the
full query​, while regular users will only see the full query for their own
queries."?

Geoff

Re: [HACKERS] [COMMITTERS] pgsql: Use gender-neutral language in documentation

[Gavin Flower]

An example from a book on PostgreSQL server programming that I'm working 
through (Note that it is obviously awkward to write with gender pronouns 
when gender is irrelevant, note the "he she" in one place and "he/she" 
in another!):


   "If the user is a superuser, then he she has permission to see the
   full query. If the user is a regular user, he/she will only see the
   full query for his/her queries."

Written in 'Gender Appropriate' style (only refer to gender when it is 
relevant):


   "If the user is a superuser, then they have permission to see the
   full query. If the user is a regular user, they will only see the
   full query for their queries."

I think the second version is easier to read - and in this case, shorter!


-Gavin



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