Re: [HACKERS] Possible spelling fixes

[Josh Soref]

0001-spelling-comments.patch
Description: Binary data


0002-spelling-strings.patch
Description: Binary data


0003-spelling-sgml.patch
Description: Binary data


0004-spelling-variables.patch
Description: Binary data


0005-spelling-misc.patch
Description: Binary data

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

Re: [HACKERS] Possible spelling fixes

[Andres Freund]

On 2017-03-01 14:40:26 -0300, Alvaro Herrera wrote:
> Josh Soref wrote:
> 
> > One thing that would be helpful is if someone could comment on:
> > https://github.com/jsoref/postgres/commit/9050882d601134ea1ba26f77ce5f1aaed75418de
> > -#undef SH_ITERTOR
> > +#undef SH_ITERATOR
> > 
> > It's unclear to me what that line is/was doing. It's possible that it
> > could be removed entirely instead of having its spelling changed.
> > If the line is trying to guard against a previous version of the code,
> > which is no longer active, then it deserves a comment.
> 
> AFAICS this is a bug.  This file can potentially be included several
> times by the same C source, and it defines SH_ITERATOR every time.  The
> second time it needs to be #undef'ed prior, which this line is supposed
> to do but fails because of the typo.

Indeed.  Fixed, thanks for noticing.

Andres


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

Re: [HACKERS] Possible spelling fixes

[Alvaro Herrera]

Josh Soref wrote:

> One thing that would be helpful is if someone could comment on:
> https://github.com/jsoref/postgres/commit/9050882d601134ea1ba26f77ce5f1aaed75418de
> -#undef SH_ITERTOR
> +#undef SH_ITERATOR
> 
> It's unclear to me what that line is/was doing. It's possible that it
> could be removed entirely instead of having its spelling changed.
> If the line is trying to guard against a previous version of the code,
> which is no longer active, then it deserves a comment.

AFAICS this is a bug.  This file can potentially be included several
times by the same C source, and it defines SH_ITERATOR every time.  The
second time it needs to be #undef'ed prior, which this line is supposed
to do but fails because of the typo.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Re: [HACKERS] Possible spelling fixes

[Josh Soref]

Peter Eisentraut wrote:
> Yes, some of that was committed, and some comments were offered.  If
> there is more to do, please send a rebased patch set.

Conflicting comments were offered. And Heikki requested I send along
the remainder. Which I did. Only one of those patches would have been
impacted by the conflicting comments.

The patches in this thread still applied today:
spelling: comments -- conflicting comments about NUL/NULL
spelling: strings -- no comments / applied cleanly
spelling: variables -- no comments / applied cleanly
spelling: misc -- no comments / applied cleanly
spelling: api -- no comments until today / applied cleanly, may end up
being dropped

I want to thank Heikki for the initial acceptance and Alvaro and David
for their additional comments.

I'm not going to send a new submission before tonight.

If anyone else wants to make comments before I resubmit, I welcome them...

For reference, my current work queue is here:
https://github.com/postgres/postgres/compare/master...jsoref:spelling-words?expand=1

The rebased version of the patches that were submitted but ignored are here:
https://github.com/postgres/postgres/compare/master...jsoref:spelling?expand=1
I haven't updated them to reflect my work queue, as selecting things
into those bundles is a not particularly pleasant, and thus a step I
want to do as few times as possible.

One thing that would be helpful is if someone could comment on:
https://github.com/jsoref/postgres/commit/9050882d601134ea1ba26f77ce5f1aaed75418de
-#undef SH_ITERTOR
+#undef SH_ITERATOR

It's unclear to me what that line is/was doing. It's possible that it
could be removed entirely instead of having its spelling changed.
If the line is trying to guard against a previous version of the code,
which is no longer active, then it deserves a comment.


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

Re: [HACKERS] Possible spelling fixes

[Josh Soref]

I'll include it.


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

Re: [HACKERS] Possible spelling fixes

[Josh Soref]

I understood that they were git commits. I could have excluded the
file but opted not to in case people were willing to take a small
drift -- the SHAs are what someone needs to review the commit, and
personally, I'd rather read something without typos than with --
especially in a summary. But, I'll tentatively exclude the lines
containing SHAs.

do you want:
@@ -3116,7 +3116,7 @@ 2016-02-17 [a5c43b886] Add new system vi


 This view exposes the same information available from
-the pg_config comand-line utility,
+the pg_config command-line utility,
 namely assorted compile-time configuration information for
 PostgreSQL.


or should I exclude the file entirely?


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

Re: [HACKERS] Possible spelling fixes

[Josh Soref]

I can easily drop the shutdown* items;

The reason for rowMarks is consistency with lr_arowMarks.

I'll tentatively exclude that from any resubmission I make tonight...


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

Re: [HACKERS] Possible spelling fixes

[Alvaro Herrera]

Josh Soref wrote:
> 

>  

Re: [HACKERS] Possible spelling fixes

[Alvaro Herrera]

Josh Soref wrote:

> - else if (ControlFile->state == DB_SHUTDOWNING)
> + else if (ControlFile->state == DB_SHUTTINGDOWN)

SHUTDOWNING and SHUTDOWNED are typos first introduced by hacker emeritus
Vadim Mikheev in 1999 together with WAL, commit 47937403676d.  It goes
to show that not every PG hacker is a learned English speaker.  I see no
reason to change the spelling.  

> - List   *epq_arowmarks;
> + List   *epq_arowMarks;

I'd not change this one either.  Of the large set of words run together
in our source, this is one of the easiest ones to read.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Re: [HACKERS] Possible spelling fixes

[Peter Eisentraut]

On 3/1/17 09:12, Josh Soref wrote:
> On Mar 1, 2017 9:06 AM, "Peter Eisentraut"
>  > wrote:
> 
> On 2/6/17 06:03, Heikki Linnakangas wrote:
> > Ah, yes please. Post them over and I'll have a look at those as well.
> 
> This thread is in the commit fest, but I think there is no current
> patch.
> 
> 
> I sent email on the 6th with a number of patches as attachments... 

Yes, some of that was committed, and some comments were offered.  If
there is more to do, please send a rebased patch set.

-- 
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Re: [HACKERS] Possible spelling fixes

[David Rowley]

On 6 February 2017 at 15:50, Josh Soref  wrote:
> It's now split more or less to your suggestion:
> https://github.com/jsoref/postgres/commits/spelling

- * Note that this algrithm is know to not be very effective (O(N^2))
+ * Note that this algorithm is know to not be very effective (O(N^2))

know should be known. Perhaps you can include if you have a followup patch.


-- 
 David Rowley   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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

Re: [HACKERS] Possible spelling fixes

[Josh Soref]

On Mar 1, 2017 9:06 AM, "Peter Eisentraut" 
wrote:

On 2/6/17 06:03, Heikki Linnakangas wrote:
> Ah, yes please. Post them over and I'll have a look at those as well.

This thread is in the commit fest, but I think there is no current patch.


I sent email on the 6th with a number of patches as attachments...

Re: [HACKERS] Possible spelling fixes

[Peter Eisentraut]

On 2/6/17 06:03, Heikki Linnakangas wrote:
> On 02/06/2017 12:52 PM, Josh Soref wrote:
>> Did you want me to submit emails for the remaining portions from
>> https://github.com/jsoref/postgres/commits/spelling
> 
> Ah, yes please. Post them over and I'll have a look at those as well.

This thread is in the commit fest, but I think there is no current patch.

-- 
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Re: [HACKERS] Possible spelling fixes

[Josh Soref]

diff --git a/src/backend/access/transam/xlog.c 
b/src/backend/access/transam/xlog.c
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -6083,7 +6083,7 @@ StartupXLOG(void)
ereport(LOG,
(errmsg("database system was shut down in 
recovery at %s",
str_time(ControlFile->time;
-   else if (ControlFile->state == DB_SHUTDOWNING)
+   else if (ControlFile->state == DB_SHUTTINGDOWN)
ereport(LOG,
(errmsg("database system shutdown was 
interrupted; last known up at %s",
str_time(ControlFile->time;
@@ -8398,7 +8398,7 @@ CreateCheckPoint(int flags)
if (shutdown)
{
LWLockAcquire(ControlFileLock, LW_EXCLUSIVE);
-   ControlFile->state = DB_SHUTDOWNING;
+   ControlFile->state = DB_SHUTTINGDOWN;
ControlFile->time = (pg_time_t) time(NULL);
UpdateControlFile();
LWLockRelease(ControlFileLock);
diff --git a/src/backend/executor/nodeLockRows.c 
b/src/backend/executor/nodeLockRows.c
--- a/src/backend/executor/nodeLockRows.c
+++ b/src/backend/executor/nodeLockRows.c
@@ -349,7 +349,7 @@ ExecInitLockRows(LockRows *node, EState 
 {
LockRowsState *lrstate;
Plan   *outerPlan = outerPlan(node);
-   List   *epq_arowmarks;
+   List   *epq_arowMarks;
ListCell   *lc;
 
/* check for unsupported flags */
@@ -398,7 +398,7 @@ ExecInitLockRows(LockRows *node, EState 
 * built the global list of ExecRowMarks.)
 */
lrstate->lr_arowMarks = NIL;
-   epq_arowmarks = NIL;
+   epq_arowMarks = NIL;
foreach(lc, node->rowMarks)
{
PlanRowMark *rc = castNode(PlanRowMark, lfirst(lc));
@@ -425,12 +425,12 @@ ExecInitLockRows(LockRows *node, EState 
if (RowMarkRequiresRowShareLock(erm->markType))
lrstate->lr_arowMarks = lappend(lrstate->lr_arowMarks, 
aerm);
else
-   epq_arowmarks = lappend(epq_arowmarks, aerm);
+   epq_arowMarks = lappend(epq_arowMarks, aerm);
}
 
/* Now we have the info needed to set up EPQ state */
EvalPlanQualInit(&lrstate->lr_epqstate, estate,
-outerPlan, epq_arowmarks, 
node->epqParam);
+outerPlan, epq_arowMarks, 
node->epqParam);
 
return lrstate;
 }
diff --git a/src/backend/executor/nodeModifyTable.c 
b/src/backend/executor/nodeModifyTable.c
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -1471,7 +1471,7 @@ ExecModifyTable(ModifyTableState *node)
junkfilter = resultRelInfo->ri_junkFilter;
estate->es_result_relation_info = resultRelInfo;
EvalPlanQualSetPlan(&node->mt_epqstate, 
subplanstate->plan,
-   
node->mt_arowmarks[node->mt_whichplan]);
+   
node->mt_arowMarks[node->mt_whichplan]);
continue;
}
else
@@ -1653,7 +1653,7 @@ ExecInitModifyTable(ModifyTable *node, E
 
mtstate->mt_plans = (PlanState **) palloc0(sizeof(PlanState *) * 
nplans);
mtstate->resultRelInfo = estate->es_result_relations + 
node->resultRelIndex;
-   mtstate->mt_arowmarks = (List **) palloc0(sizeof(List *) * nplans);
+   mtstate->mt_arowMarks = (List **) palloc0(sizeof(List *) * nplans);
mtstate->mt_nplans = nplans;
mtstate->mt_onconflict = node->onConflictAction;
mtstate->mt_arbiterindexes = node->arbiterIndexes;
@@ -1975,7 +1975,7 @@ ExecInitModifyTable(ModifyTable *node, E
 
subplan = mtstate->mt_plans[i]->plan;
aerm = ExecBuildAuxRowMark(erm, subplan->targetlist);
-   mtstate->mt_arowmarks[i] = 
lappend(mtstate->mt_arowmarks[i], aerm);
+   mtstate->mt_arowMarks[i] = 
lappend(mtstate->mt_arowMarks[i], aerm);
}
}
 
@@ -1983,7 +1983,7 @@ ExecInitModifyTable(ModifyTable *node, E
mtstate->mt_whichplan = 0;
subplan = (Plan *) linitial(node->plans);
EvalPlanQualSetPlan(&mtstate->mt_epqstate, subplan,
-   mtstate->mt_arowmarks[0]);
+   mtstate->mt_arowMarks[0]);
 
/*
 * Initialize the junk filter(s) if needed.  INSERT queries need a 
filter
diff --git a/src/bin/pg_controldata/pg_controldata.c 
b/src/bin/pg_controldata/pg_controldata.c
--- a/src/bin/pg_controldata/pg_controldata.c
++

Re: [HACKERS] Possible spelling fixes

[Josh Soref]

diff --git a/src/test/regress/sql/plpgsql.sql b/src/test/regress/sql/plpgsql.sql
--- a/src/test/regress/sql/plpgsql.sql
+++ b/src/test/regress/sql/plpgsql.sql
@@ -2219,15 +2219,15 @@ drop type eitype cascade;
 -- SQLSTATE and SQLERRM test
 --
 
-create function excpt_test1() returns void as $$
+create function except_test1() returns void as $$
 begin
 raise notice '% %', sqlstate, sqlerrm;
 end; $$ language plpgsql;
 -- should fail: SQLSTATE and SQLERRM are only in defined EXCEPTION
 -- blocks
-select excpt_test1();
-
-create function excpt_test2() returns void as $$
+select except_test1();
+
+create function except_test2() returns void as $$
 begin
 begin
 begin
@@ -2236,9 +2236,9 @@ begin
 end;
 end; $$ language plpgsql;
 -- should fail
-select excpt_test2();
-
-create function excpt_test3() returns void as $$
+select except_test2();
+
+create function except_test3() returns void as $$
 begin
 begin
 raise exception 'user exception';
@@ -2257,19 +2257,19 @@ begin
raise notice '% %', sqlstate, sqlerrm;
 end;
 end; $$ language plpgsql;
-select excpt_test3();
-
-create function excpt_test4() returns text as $$
+select except_test3();
+
+create function except_test4() returns text as $$
 begin
begin perform 1/0;
exception when others then return sqlerrm; end;
 end; $$ language plpgsql;
-select excpt_test4();
-
-drop function excpt_test1();
-drop function excpt_test2();
-drop function excpt_test3();
-drop function excpt_test4();
+select except_test4();
+
+drop function except_test1();
+drop function except_test2();
+drop function except_test3();
+drop function except_test4();
 
 -- parameters of raise stmt can be expressions
 create function raise_exprs() returns void as $$

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

Re: [HACKERS] Possible spelling fixes

[Josh Soref]

diff --git a/src/backend/access/transam/multixact.c 
b/src/backend/access/transam/multixact.c
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -3342,7 +3342,7 @@ pg_get_multixact_members(PG_FUNCTION_ARG
} mxact;
MultiXactId mxid = PG_GETARG_UINT32(0);
mxact  *multi;
-   FuncCallContext *funccxt;
+   FuncCallContext *funcctx;
 
if (mxid < FirstMultiXactId)
ereport(ERROR,
@@ -3354,8 +3354,8 @@ pg_get_multixact_members(PG_FUNCTION_ARG
MemoryContext oldcxt;
TupleDesc   tupdesc;
 
-   funccxt = SRF_FIRSTCALL_INIT();
-   oldcxt = MemoryContextSwitchTo(funccxt->multi_call_memory_ctx);
+   funcctx = SRF_FIRSTCALL_INIT();
+   oldcxt = MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
 
multi = palloc(sizeof(mxact));
/* no need to allow for old values here */
@@ -3369,14 +3369,14 @@ pg_get_multixact_members(PG_FUNCTION_ARG
TupleDescInitEntry(tupdesc, (AttrNumber) 2, "mode",
   TEXTOID, -1, 0);
 
-   funccxt->attinmeta = TupleDescGetAttInMetadata(tupdesc);
-   funccxt->user_fctx = multi;
+   funcctx->attinmeta = TupleDescGetAttInMetadata(tupdesc);
+   funcctx->user_fctx = multi;
 
MemoryContextSwitchTo(oldcxt);
}
 
-   funccxt = SRF_PERCALL_SETUP();
-   multi = (mxact *) funccxt->user_fctx;
+   funcctx = SRF_PERCALL_SETUP();
+   multi = (mxact *) funcctx->user_fctx;
 
while (multi->iter < multi->nmembers)
{
@@ -3386,16 +3386,16 @@ pg_get_multixact_members(PG_FUNCTION_ARG
values[0] = psprintf("%u", multi->members[multi->iter].xid);
values[1] = 
mxstatus_to_string(multi->members[multi->iter].status);
 
-   tuple = BuildTupleFromCStrings(funccxt->attinmeta, values);
+   tuple = BuildTupleFromCStrings(funcctx->attinmeta, values);
 
multi->iter++;
pfree(values[0]);
-   SRF_RETURN_NEXT(funccxt, HeapTupleGetDatum(tuple));
+   SRF_RETURN_NEXT(funcctx, HeapTupleGetDatum(tuple));
}
 
if (multi->nmembers > 0)
pfree(multi->members);
pfree(multi);
 
-   SRF_RETURN_DONE(funccxt);
+   SRF_RETURN_DONE(funcctx);
 }
diff --git a/src/backend/access/transam/xlog.c 
b/src/backend/access/transam/xlog.c
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -851,7 +851,7 @@ static bool InstallXLogFileSegment(XLogS
   bool find_free, XLogSegNo max_segno,
   bool use_lock);
 static int XLogFileRead(XLogSegNo segno, int emode, TimeLineID tli,
-int source, bool notexistOk);
+int source, bool notfoundOk);
 static int XLogFileReadAnyTLI(XLogSegNo segno, int emode, int source);
 static int XLogPageRead(XLogReaderState *xlogreader, XLogRecPtr targetPagePtr,
 int reqLen, XLogRecPtr targetRecPtr, char *readBuf,
diff --git a/src/backend/executor/nodeAgg.c b/src/backend/executor/nodeAgg.c
--- a/src/backend/executor/nodeAgg.c
+++ b/src/backend/executor/nodeAgg.c
@@ -486,7 +486,7 @@ static void agg_fill_hash_table(AggState
 static TupleTableSlot *agg_retrieve_hash_table(AggState *aggstate);
 static Datum GetAggInitVal(Datum textInitVal, Oid transtype);
 static void build_pertrans_for_aggref(AggStatePerTrans pertrans,
- AggState *aggsate, EState 
*estate,
+ AggState *aggstate, EState 
*estate,
  Aggref *aggref, Oid 
aggtransfn, Oid aggtranstype,
  Oid aggserialfn, Oid 
aggdeserialfn,
  Datum initValue, bool 
initValueIsNull,
diff --git a/src/backend/replication/walreceiverfuncs.c 
b/src/backend/replication/walreceiverfuncs.c
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -322,7 +322,7 @@ GetReplicationApplyDelay(void)
longsecs;
int usecs;
 
-   TimestampTz chunckReplayStartTime;
+   TimestampTz chunkReplayStartTime;
 
SpinLockAcquire(&walrcv->mutex);
receivePtr = walrcv->receivedUpto;
@@ -333,12 +333,12 @@ GetReplicationApplyDelay(void)
if (receivePtr == replayPtr)
return 0;
 
-   chunckReplayStartTime = GetCurrentChunkReplayStartTime();
+   chunkReplayStartTime = GetCurrentChunkReplayStartTime();
 
-   if (chunckReplayStartTime == 0)
+   if (chunkReplayStartTime == 0)
return -1;
 
-   TimestampDifference(chunckR

Re: [HACKERS] Possible spelling fixes

[Josh Soref]

diff --git a/contrib/ltree/ltxtquery_io.c b/contrib/ltree/ltxtquery_io.c
--- a/contrib/ltree/ltxtquery_io.c
+++ b/contrib/ltree/ltxtquery_io.c
@@ -96,7 +96,7 @@ gettoken_query(QPRS_STATE *state, int32 
if (*flag)
ereport(ERROR,

(errcode(ERRCODE_SYNTAX_ERROR),
-
errmsg("modificators syntax error")));
+
errmsg("modifiers syntax error")));
*lenval += charlen;
}
else if (charlen == 1 && t_iseq(state->buf, 
'%'))
diff --git a/doc/src/sgml/biblio.sgml b/doc/src/sgml/biblio.sgml
--- a/doc/src/sgml/biblio.sgml
+++ b/doc/src/sgml/biblio.sgml
@@ -295,7 +295,7 @@ ssimk...@ag.or.at
 April, 1990
 
  University  of  California
- Berkely, California
+ Berkeley, California
 


diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -1225,7 +1225,7 @@ postgres   27093  0.0  0.0  30096  2752 
 
 
  MessageQueuePutMessage
- Waiting to write a protoocol message to a shared message 
queue.
+ Waiting to write a protocol message to a shared message 
queue.
 
 
  MessageQueueReceive
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -5882,7 +5882,7 @@ TupleData
 
 
 
-Idenfifies the data as NULL value.
+Identifies the data as NULL value.
 
 
 
@@ -5895,7 +5895,7 @@ TupleData
 
 
 
-Idenfifies unchanged TOASTed value (the actual value is not
+Identifies unchanged TOASTed value (the actual value is not
 sent).
 
 
@@ -5909,7 +5909,7 @@ TupleData
 
 
 
-Idenfifies the data as text formatted value.
+Identifies the data as text formatted value.
 
 
 
diff --git a/doc/src/sgml/ref/create_subscription.sgml 
b/doc/src/sgml/ref/create_subscription.sgml
--- a/doc/src/sgml/ref/create_subscription.sgml
+++ b/doc/src/sgml/ref/create_subscription.sgml
@@ -131,7 +131,7 @@ CREATE SUBSCRIPTION  option -g
-to specify role membership (Chistopher Browne)
+to specify role membership (Christopher Browne)

   
 
diff --git a/doc/src/sgml/release-9.6.sgml b/doc/src/sgml/release-9.6.sgml
--- a/doc/src/sgml/release-9.6.sgml
+++ b/doc/src/sgml/release-9.6.sgml
@@ -2783,7 +2783,7 @@ 2015-12-30 [e84290823] Avoid useless tru
   
 

 Improve full-text search to support
@@ -4612,7 +4612,7 @@ 2016-02-16 [fc1ae7d2e] Change ecpg lexer
 
   
 

 Add a --strict-names option
@@ -5609,7 +5609,7 @@ 2016-03-16 [f576b17cd] Add word_similari
 
   
 

diff --git a/doc/src/sgml/release-old.sgml b/doc/src/sgml/release-old.sgml
--- a/doc/src/sgml/release-old.sgml
+++ b/doc/src/sgml/release-old.sgml
@@ -5737,8 +5737,8 @@ fix rtree for use in inner scan (Vadim)
 fix gist for use in inner scan, cleanups (Vadim, Andrea)
 avoid unnecessary local buffers allocation (Vadim, Massimo)
 fix local buffers leak in transaction aborts (Vadim)
-fix file manager memmory leaks, cleanups (Vadim, Massimo)
-fix storage manager memmory leaks (Vadim)
+fix file manager memory leaks, cleanups (Vadim, Massimo)
+fix storage manager memory leaks (Vadim)
 fix btree duplicates handling (Vadim)
 fix deleted rows reincarnation caused by vacuum (Vadim)
 fix SELECT varchar()/char() INTO TABLE made zero-length fields(Bruce)
@@ -5904,7 +5904,7 @@ European date format now set when postma
 Execute lowercase function names if not found with exact case
 Fixes for aggregate/GROUP processing, allow 'select sum(func(x),sum(x+y) from 
z'
 Gist now included in the distribution(Marc)
-Idend authentication of local users(Bryan)
+Ident authentication of local users(Bryan)
 Implement BETWEEN qualifier(Bruce)
 Implement IN qualifier(Bruce)
 libpq has PQgetisnull()(Bruce)
diff --git a/src/backend/optimizer/geqo/geqo_erx.c 
b/src/backend/optimizer/geqo/geqo_erx.c
--- a/src/backend/optimizer/geqo/geqo_erx.c
+++ b/src/backend/optimizer/geqo/geqo_erx.c
@@ -458,7 +458,7 @@ edge_failure(PlannerInfo *root, Gene *ge
if (edge_table[i].unused_edges >= 0)
return (Gene) i;
 
-   elog(LOG, "no edge found via looking for the last ununsed 
point");
+   elog(LOG, "no edge found via looking for the last unused 
point");
}
 
 
diff --git a/src/backend/port/dynloader/linux.c 
b/src/backend/port/dynloader/linux.c
--- a/src/backend/port/dynloader/linux.c
+++ b/src/backend/port/dynloader/linux.c
@@ -124,7 +124,7 @@ char *
 pg

Re: [HACKERS] Possible spelling fixes

[Piotr Stefaniak]

On 2017-02-06 10:40, Heikki Linnakangas wrote:
> On 02/06/2017 04:50 AM, Josh Soref wrote:
>> NUL-terminated -> NULL-terminated
> 
> When we're talking about NUL-terminated strings, NUL refers to the NUL
> ASCII character. NULL usually refers to a NULL pointer. We're probably
> not consistent about this, but in this context, NUL-terminated isn't
> wrong, so let's leave them as they are.

The C standard talks about how "a byte with all bits set to 0, called
the null character" is used to "terminate a character string"; it
mentions '\0' as "commonly used to represent the null character"; and it
also talks about when snprintf() produces "null-terminated output".

It never mentions ASCII in this context; quite intentionally it avoids
assuming ASCII at all, so that a standard-compliant C implementation may
co-exist with other encodings (like EBCDIC).



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

Re: [HACKERS] Possible spelling fixes

[Alvaro Herrera]

Andres Freund wrote:

> On 2017-02-05 21:05:50 -0500, Josh Soref wrote:

> > A complete diff would be roughly 130k. I've recently tried to submit a
> > similarly sized patch to another project and it was stuck in
> > moderation (typically mailing lists limit attachments to around 40k).
> 
> IIRC 130k shouln't get you stuck in filters yet - if you're concerned
> you can gzip the individual patches.

Our limit for pgsql-hackers is 1 MB.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Re: [HACKERS] Possible spelling fixes

[Heikki Linnakangas]

On 02/06/2017 12:52 PM, Josh Soref wrote:

Did you want me to submit emails for the remaining portions from
https://github.com/jsoref/postgres/commits/spelling


Ah, yes please. Post them over and I'll have a look at those as well.

- Heikki



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

Re: [HACKERS] Possible spelling fixes

[Josh Soref]

Heikki wrote:
‎> I pushed most of these. Except for the below:
> optimisation -> optimization et al.

> Most of our code is written with the American spelling,
> but the British spelling isn't wrong,
> so I don't want to go around changing them all.

Sure

As you'll see, my approach is to aim for consistency. If you used en-GB 99% of 
the time, I'd have offered a change to enforce that. I have a personal 
preference, but there's no obligation, and I understand the potential costs 
churn entails (I see you backported to branches). 

> NUL-terminated -> NULL-terminated

> When we're talking about NUL-terminated strings,
> NUL refers to the NUL ASCII character. NULL usually refers to a NULL pointer.

This wasn't even in my original set (i.e. The dictionary I'm using didn't 
consider NUL to be misspelled). I ran across it while splitting comments out 
per Andres and figured I'd offer it as well. 

> We're probably not consistent about this,

Hrm, I was going to say "that's correct, you aren't", but rereading, I realize 
that I'd have to review every instance in order to prove to myself that 
statement. I could make the weaker argument that "nul-terminated" should be 
changed to either NUL-terminated or null-terminated . My general approach is to 
only make changes when I can detect an inconsistency. And I generally tend 
toward "majority rule".

Here, I think the corpus has 4 spellings, and it sounds like it should only 
have two, but probably (NUL- and null-) not the two I picked (NULL- and null-). 

> but in this context, NUL-terminated isn't wrong, so let's leave them as they 
> are.

But that's OK. My goal in posting these is to encourage people to consider 
their code. 

>> Ooops -> Oops

> "Oops" is more idiomatic, but this doesn't really seem worth changing. 

Technically oops is in dictionaries whereas the other isn't, but I understood 
the intent. 

> Maybe "Ooops" indicates a slightly bigger mistake than "oops" :-)

That seemed like the intent. It's certainly not unreasonable to retain it. It's 
also why I generally offer a queue, so people can reject families of changes. 

>> re-entrancy -> reentrancy

> Googling around, I can see both spellings being used.

Both are used, but reentrancy is in most dictionaries (and encyclopedias) and 
is the form that's used in instruction (certainly it was when I studied in 
university, and it isn't likely to regress). It's akin to email vs e-mail. Once 
the dashless form becomes accepted (within a domain [1]), it's the correct 
form, and the other was merely transitional. 

> "Re-entrancy" actually feels more natural to me, although I'm not sure which 
> is more correct.
> Let's leave them as they are.

Sure 

>> passthru -> passthrough

> "Passthrough" is clearly the correct spelling (or "pass-through"?),

The former is also present in the codebase. (I didn't look for the latter, for 
the same reason as the previous note.)

> but "passthru" seems OK in the context, as an informal shorthand.

My goal is consistency. If you always spell a concept a single way, then 
grepping for that concept is easier and more reliable. 

I personally recognize quite a few flavors, because they're usable for talking 
to Coverity / Purify. 

>> - * Temporay we use TSLexeme.flags for inner use...
>> + * Temporary we use TSLexeme.flags for inner use...

> Looking at the code real quick, I couldn't understand the original 
meaning of this. Is it:
> * DT_USEASIS is a temporary value we use for something. For what?
> * DT_USEASIS is used temporarily for something.
> Does this mean, "temporarily" until we get around to write the code 
> differently, or does 
> it happen temporarily at runtime, or what?

> Just fixing the typo doesn't help much here,
> and I'm not sure if it should be "temporary" or "temporarily" anyway.

Apparently I didn't look at this one much at all. I believe temporarily is the 
intended word (fwiw, I originally mis-corrected directly as directory, that I 
did spot before submitting). And probably as a runtime concept. 

But I'm not volunteering to fix all comments in the project ;-). After spelling 
fixes, I'm more likely to try actual bugs / usability issues. I have a specific 
bug which bit me, but fixing that would require more effort than a spelling 
pass and more cooperation. I tend to do a spelling pass to determine if the 
more expensive activity is viable. So far, the project is welcoming :-) so, 
perhaps I'll manage to write the real fix...

> I wasn't sure if this changes the meaning of the comment slightly.
> An "UPDATE" in all-caps refers to an UPDATE statement,
> is that what's meant here? Or just updating a tuple,
> i.e. should this rather be "skip updating of the tuple" or "skip update of 
> tuple"?

I'm not certain. I do understand that capital UPDATE is special. This one 
people more familiar with the project will have to resolve. 

Fwiw, if it's the former, you could omit the "of".

> This "postsql" refers to the SQL dialect of PostgreSQL,

I had t

Re: [HACKERS] Possible spelling fixes

[Heikki Linnakangas]

On 02/06/2017 04:50 AM, Josh Soref wrote:

It's now split more or less to your suggestion:
https://github.com/jsoref/postgres/commits/spelling


Thanks!

I pushed most of these. Except for the below:


optimisation -> optimization et al.


Most of our code is written with the American spelling, but the British 
spelling isn't wrong, so I don't want to go around changing them all.



NUL-terminated -> NULL-terminated


When we're talking about NUL-terminated strings, NUL refers to the NUL 
ASCII character. NULL usually refers to a NULL pointer. We're probably 
not consistent about this, but in this context, NUL-terminated isn't 
wrong, so let's leave them as they are.



Ooops -> Oops


"Oops" is more idiomatic, but this doesn't really seem worth changing. 
Maybe "Ooops" indicates a slightly bigger mistake than "oops" :-)



re-entrancy -> reentrancy


Googling around, I can see both spellings being used. "Re-entrancy" 
actually feels more natural to me, although I'm not sure which is more 
correct. Let's leave them as they are.



passthru -> passthrough


"Passthrough" is clearly the correct spelling (or "pass-through"?), but 
"passthru" seems OK in the context, as an informal shorthand.



--- a/src/backend/tsearch/dict_thesaurus.c
+++ b/src/backend/tsearch/dict_thesaurus.c
@@ -23,7 +23,7 @@


 /*
- * Temporay we use TSLexeme.flags for inner use...
+ * Temporary we use TSLexeme.flags for inner use...
  */
 #define DT_USEASIS 0x1000


Looking at the code real quick, I couldn't understand the original 
meaning of this. Is it:


* DT_USEASIS is a temporary value we use for something. For what?

* DT_USEASIS is used temporarily for something. Does this mean, 
"temporarily" until we get around to write the code differently, or does 
it happen temporarily at runtime, or what?


Just fixing the typo doesn't help much here, and I'm not sure if it 
should be "temporary" or "temporarily" anyway.



--- a/contrib/spi/timetravel.c
+++ b/contrib/spi/timetravel.c
@@ -51,7 +51,7 @@ static EPlan *find_plan(char *ident, EPlan **eplan, int 
*nplans);
  * and stop_date eq INFINITY [ and update_user eq current 
user ]
  * and all other column values as in new tuple, and insert 
tuple
  * with old data and stop_date eq current date
- * ELSE - skip updation of tuple.
+ * ELSE - skip UPDATE of tuple.
  * 2.  IF a delete affects tuple with stop_date eq INFINITY
  * then insert the same tuple with stop_date eq current 
date
  * [ and delete_user eq current user ]


I wasn't sure if this changes the meaning of the comment slightly. An 
"UPDATE" in all-caps refers to an UPDATE statement, is that what's meant 
here? Or just updating a tuple, i.e. should this rather be "skip 
updating of the tuple" or "skip update of tuple"?



--- a/src/test/regress/sql/errors.sql
+++ b/src/test/regress/sql/errors.sql
@@ -2,7 +2,7 @@
 -- ERRORS
 --

--- bad in postquel, but ok in postsql
+-- bad in postquel, but ok in PostgreSQL
 select 1;


This "postsql" refers to the SQL dialect of PostgreSQL, rather than 
PostgreSQL the project. I don't remember seeing it called "postsql" 
anywhere else, though. We hardly care about what was an error in 
postqual anyway, though, so perhaps this should be rewritten into 
something else entirely, like "This is not allowed by the SQL standard, 
but ok on PostgreSQL" (assuming that's correct, I'm not 100% sure). Or 
just leave it alone.


Thanks for the fixes! I was particularly impressed that you caught the 
typo in Marcel Kornacker's surname.


- Heikki


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

Re: [HACKERS] Possible spelling fixes

[Josh Soref]

It's now split more or less to your suggestion:
https://github.com/jsoref/postgres/commits/spelling
diff --git a/configure b/configure
--- a/configure
+++ b/configure
@@ -7088,7 +7088,7 @@ test -z "$INSTALL_SCRIPT" && INSTALL_SCR
 test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644'
 
 # When Autoconf chooses install-sh as install program it tries to generate
-# a relative path to it in each makefile where it subsitutes it. This clashes
+# a relative path to it in each makefile where it substitutes it. This clashes
 # with our Makefile.global concept. This workaround helps.
 case $INSTALL in
   *install-sh*) install_bin='';;
@@ -7232,7 +7232,7 @@ fi
 $as_echo "$MKDIR_P" >&6; }
 
 # When Autoconf chooses install-sh as mkdir -p program it tries to generate
-# a relative path to it in each makefile where it subsitutes it. This clashes
+# a relative path to it in each makefile where it substitutes it. This clashes
 # with our Makefile.global concept. This workaround helps.
 case $MKDIR_P in
   *install-sh*) MKDIR_P='\${SHELL} \${top_srcdir}/config/install-sh -c -d';;
diff --git a/configure.in b/configure.in
--- a/configure.in
+++ b/configure.in
@@ -887,7 +887,7 @@ fi
 
 AC_PROG_INSTALL
 # When Autoconf chooses install-sh as install program it tries to generate
-# a relative path to it in each makefile where it subsitutes it. This clashes
+# a relative path to it in each makefile where it substitutes it. This clashes
 # with our Makefile.global concept. This workaround helps.
 case $INSTALL in
   *install-sh*) install_bin='';;
@@ -900,7 +900,7 @@ AC_PROG_LN_S
 AC_PROG_AWK
 AC_PROG_MKDIR_P
 # When Autoconf chooses install-sh as mkdir -p program it tries to generate
-# a relative path to it in each makefile where it subsitutes it. This clashes
+# a relative path to it in each makefile where it substitutes it. This clashes
 # with our Makefile.global concept. This workaround helps.
 case $MKDIR_P in
   *install-sh*) MKDIR_P='\${SHELL} \${top_srcdir}/config/install-sh -c -d';;
diff --git a/contrib/bloom/blvacuum.c b/contrib/bloom/blvacuum.c
--- a/contrib/bloom/blvacuum.c
+++ b/contrib/bloom/blvacuum.c
@@ -51,7 +51,7 @@ blbulkdelete(IndexVacuumInfo *info, Inde
initBloomState(&state, index);
 
/*
-* Interate over the pages. We don't care about concurrently added 
pages,
+* Iterate over the pages. We don't care about concurrently added pages,
 * they can't contain tuples to delete.
 */
npages = RelationGetNumberOfBlocks(index);
diff --git a/contrib/cube/sql/cube.sql b/contrib/cube/sql/cube.sql
--- a/contrib/cube/sql/cube.sql
+++ b/contrib/cube/sql/cube.sql
@@ -256,7 +256,7 @@ SELECT cube_dim('(0,0,0)'::cube);
 SELECT cube_dim('(42,42,42),(42,42,42)'::cube);
 SELECT cube_dim('(4,8,15,16,23),(4,8,15,16,23)'::cube);
 
--- Test of cube_ll_coord function (retrieves LL coodinate values)
+-- Test of cube_ll_coord function (retrieves LL coordinate values)
 --
 SELECT cube_ll_coord('(-1,1),(2,-2)'::cube, 1);
 SELECT cube_ll_coord('(-1,1),(2,-2)'::cube, 2);
@@ -268,7 +268,7 @@ SELECT cube_ll_coord('(42,137)'::cube, 1
 SELECT cube_ll_coord('(42,137)'::cube, 2);
 SELECT cube_ll_coord('(42,137)'::cube, 3);
 
--- Test of cube_ur_coord function (retrieves UR coodinate values)
+-- Test of cube_ur_coord function (retrieves UR coordinate values)
 --
 SELECT cube_ur_coord('(-1,1),(2,-2)'::cube, 1);
 SELECT cube_ur_coord('(-1,1),(2,-2)'::cube, 2);
diff --git a/contrib/earthdistance/earthdistance--1.1.sql 
b/contrib/earthdistance/earthdistance--1.1.sql
--- a/contrib/earthdistance/earthdistance--1.1.sql
+++ b/contrib/earthdistance/earthdistance--1.1.sql
@@ -11,7 +11,7 @@ CREATE FUNCTION earth() RETURNS float8
 LANGUAGE SQL IMMUTABLE PARALLEL SAFE
 AS 'SELECT ''6378168''::float8';
 
--- Astromers may want to change the earth function so that distances will be
+-- Astronomers may want to change the earth function so that distances will be
 -- returned in degrees. To do this comment out the above definition and
 -- uncomment the one below. Note that doing this will break the regression
 -- tests.
diff --git a/contrib/isn/ISSN.h b/contrib/isn/ISSN.h
--- a/contrib/isn/ISSN.h
+++ b/contrib/isn/ISSN.h
@@ -23,7 +23,7 @@
  * Product 9 + 21 + 7 + 3 + 1 + 12 + 4 + 24 + 7 + 15 + 0 + 0 = 103
  * 103 / 10 = 10 remainder 3
  * Check digit 10 - 3 = 7
- * => 977-1144875-00-7 ??  <- suplemental number (number of the week, month, 
etc.)
+ * => 977-1144875-00-7 ??  <- supplemental number (number of the week, month, 
etc.)
  *   ^^ 00 for non-daily publications (01=Monday, 
02=Tuesday, ...)
  *
  * The hyphenation is always in after the four digits of the ISSN code.
diff --git a/contrib/isn/isn.c b/contrib/isn/isn.c
--- a/contrib/isn/isn.c
+++ b/contrib/isn/isn.c
@@ -160,7 +160,7 @@ dehyphenate(char *bufO, char *bufI)
  *   into bufO using the given hyphenation range 
TABLE.
  *  

Re: [HACKERS] Possible spelling fixes

[Andres Freund]

Hi,

On 2017-02-05 21:05:50 -0500, Josh Soref wrote:
> Could someone please review the changes I have [3] and suggest a
> series of commits that this project might like?

I think the current split seem excessive...  I'd suggest splitting
things first into:
- straight up spelling/typo fixes in comments etc.
- straight up spelling/typo fixes in variable names etc
- straight up spelling/typo fixes that are API relevant
- the same split for stuff more dependenant on taste

Then afterwards we can see what's remaining.

> A complete diff would be roughly 130k. I've recently tried to submit a
> similarly sized patch to another project and it was stuck in
> moderation (typically mailing lists limit attachments to around 40k).

IIRC 130k shouln't get you stuck in filters yet - if you're concerned
you can gzip the individual patches.


> I understand that people
> don't care about diffstats (I certainly don't), but for reference
> collectively this encompasses 175 files and 305 lines.

FWIW, I do ;)

Greetings,

Andres Freund


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

[HACKERS] Possible spelling fixes

[Josh Soref]

Hi.
I'm going through project-by-project offering spelling fixes.
I have read your submission suggestions [1][2] and am choosing to
disregard them.

Could someone please review the changes I have [3] and suggest a
series of commits that this project might like?

It is quite likely that someone will tell me that there are certain
types of changes that you don't want. That's fine, I'm happy to drop
changes. It's possible that I've chosen the wrong spelling correction
or made a mistake in my attempts, while the process of identifying
errant words is somewhat automated, the correction process is a mix of
me and some scripts, and neither of us are perfect.

The patch queue is currently sorted alphabetically, but it contains at least:
* branding corrections -- some of which may be wrong
* regional English -- I understand there's a discussion about this, I
can easily drop them, or you can choose to take them separately
* changelog changes -- I could understand not wanting to change the changelog
* local variable changes
* API changes -- hopefully the changes to functions/enums are within
private space and thus not a problem, but if you consider them to be
public, dropping them isn't a big deal
* changes to tests -- it wouldn't shock me if I messed some of these
up. Again, everything can be split/dropped/fixed if requested (within
limits -- I refuse to submit 100 emails with patches)
* changes to comments, lots of comments

Most changes are just changes to comments, and I'd hope it wouldn't be
terribly hard for them to be accepted.
A complete diff would be roughly 130k. I've recently tried to submit a
similarly sized patch to another project and it was stuck in
moderation (typically mailing lists limit attachments to around 40k).

I do not expect anyone to be able to do anything remotely useful with
such a patch. It is certainly possible for someone else to generate
such a file if they really like reading a diff in that manner.

For reference, I've split my proposal into 172 changes. Each change
should represent a single word/concept which has been misspelled
(possibly in multiple different manners). I understand that people
don't care about diffstats (I certainly don't), but for reference
collectively this encompasses 175 files and 305 lines.

Note that I've intentionally excluded certain files (by removing them
in prior commits), it's possible that changes would be needed to be
made to some of those files in order for tests to pass. If you have an
automated system for running tests (typically Travis or Appveyor), I'm
happy to submit changes to them before offering changes to a list. But
I couldn't find anything of the sort.

[1] https://wiki.postgresql.org/wiki/Submitting_a_Patch
[2] http://petereisentraut.blogspot.ca/2009/09/how-to-submit-patch-by-email.html
[3] https://github.com/jsoref/postgres/compare/ignore...jsoref:spelling?expand=1


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