pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedfix typos
27+ messages / 13 participants
[nested] [flat]
* fix typos
@ 2015-05-17 11:46 Dmitriy Olshevskiy <olshevskiy87@bk.ru>
2015-05-17 12:58 ` Re: fix typos Magnus Hagander <magnus@hagander.net>
0 siblings, 1 reply; 27+ messages in thread
From: Dmitriy Olshevskiy @ 2015-05-17 11:46 UTC (permalink / raw)
To: pgsql-hackers
Hello. Please, see this patch with typos.
Thank you.
--
Dmitriy Olshevskiy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[text/x-patch] 0001-fix-typos.patch (10.0K, ../../55587FAA.5010000@bk.ru/2-0001-fix-typos.patch)
download | inline diff:
From e9c463e50efdaa1fbdcabea92cd95cbffea3d3bd Mon Sep 17 00:00:00 2001
From: olshevskiy87 <olshevskiy87@bk.ru>
Date: Sun, 17 May 2015 15:40:40 +0400
Subject: [PATCH] fix typos
---
contrib/tsm_system_time/tsm_system_time.c | 2 +-
doc/src/sgml/logicaldecoding.sgml | 2 +-
doc/src/sgml/ref/pg_dumpall.sgml | 2 +-
src/backend/access/gin/ginpostinglist.c | 14 +++++++-------
src/backend/access/heap/heapam.c | 2 +-
src/backend/access/nbtree/README | 2 +-
src/backend/access/transam/xact.c | 4 ++--
src/backend/replication/logical/snapbuild.c | 2 +-
src/backend/tsearch/dict_synonym.c | 2 +-
src/backend/utils/adt/jsonfuncs.c | 2 +-
src/test/regress/expected/event_trigger.out | 2 +-
src/test/regress/sql/event_trigger.sql | 2 +-
12 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/contrib/tsm_system_time/tsm_system_time.c b/contrib/tsm_system_time/tsm_system_time.c
index efb127c..9af9e74 100644
--- a/contrib/tsm_system_time/tsm_system_time.c
+++ b/contrib/tsm_system_time/tsm_system_time.c
@@ -267,7 +267,7 @@ tsm_system_time_cost(PG_FUNCTION_ARGS)
NULL);
/*
- * Assumption here is that we'll never read less then 1% of table pages,
+ * Assumption here is that we'll never read less than 1% of table pages,
* this is here mainly because it is much less bad to overestimate than
* underestimate and using just spc_random_page_cost will probably lead
* to underestimations in general.
diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml
index 00f6eee..5fa2f77 100644
--- a/doc/src/sgml/logicaldecoding.sgml
+++ b/doc/src/sgml/logicaldecoding.sgml
@@ -649,7 +649,7 @@ OutputPluginWrite(ctx, true);
<title>Synchronous Replication Support for Logical Decoding</title>
<para>
- Logical decoding can be used to to build
+ Logical decoding can be used to build
<link linkend="synchronous-replication">synchronous
replication</link> solutions with the same user interface as synchronous
replication for <link linkend="streaming-replication">streaming
diff --git a/doc/src/sgml/ref/pg_dumpall.sgml b/doc/src/sgml/ref/pg_dumpall.sgml
index fcf5f77..0444f09 100644
--- a/doc/src/sgml/ref/pg_dumpall.sgml
+++ b/doc/src/sgml/ref/pg_dumpall.sgml
@@ -454,7 +454,7 @@ PostgreSQL documentation
<term><option>--database=<replaceable>dbname</replaceable></option></term>
<listitem>
<para>
- Specifies the name of the database to connect to to dump global
+ Specifies the name of the database to connect to dump global
objects and discover what other databases should be dumped. If
not specified, the <literal>postgres</literal> database will be used,
and if that does not exist, <literal>template1</literal> will be used.
diff --git a/src/backend/access/gin/ginpostinglist.c b/src/backend/access/gin/ginpostinglist.c
index 6337b1a..e6d7c1a 100644
--- a/src/backend/access/gin/ginpostinglist.c
+++ b/src/backend/access/gin/ginpostinglist.c
@@ -23,7 +23,7 @@
/*
* For encoding purposes, item pointers are represented as 64-bit unsigned
* integers. The lowest 11 bits represent the offset number, and the next
- * lowest 32 bits are the block number. That leaves 17 bits unused, ie.
+ * lowest 32 bits are the block number. That leaves 17 bits unused, i.e.
* only 43 low bits are used.
*
* These 43-bit integers are encoded using varbyte encoding. In each byte,
@@ -51,16 +51,16 @@
* Removing number is actually replacement of two numbers with their sum. We
* have to prove that varbyte encoding of a sum can't be longer than varbyte
* encoding of its summands. Sum of two numbers is at most one bit wider than
- * than the larger of the summands. Widening a number by one bit enlarges its
- * length in varbyte encoding by at most one byte. Therefore, varbyte encoding
- * of sum is at most one byte longer than varbyte encoding of larger summand.
- * Lesser summand is at least one byte, so the sum cannot take more space than
- * the summands, Q.E.D.
+ * the larger of the summands. Widening a number by one bit enlarges its length
+ * in varbyte encoding by at most one byte. Therefore, varbyte encoding of sum
+ * is at most one byte longer than varbyte encoding of larger summand. Lesser
+ * summand is at least one byte, so the sum cannot take more space than the
+ * summands, Q.E.D.
*
* This property greatly simplifies VACUUM, which can assume that posting
* lists always fit on the same page after vacuuming. Note that even though
* that holds for removing items from a posting list, you must also be
- * careful to not cause expansion e.g when merging uncompressed items on the
+ * careful to not cause expansion e.g. when merging uncompressed items on the
* page into the compressed lists, when vacuuming.
*/
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index f0c2394..c30a5b3 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -7289,7 +7289,7 @@ ExtractReplicaIdentity(Relation relation, HeapTuple tp, bool key_changed, bool *
{
/*
* The OID column can appear in an index definition, but that's
- * OK, becuse we always copy the OID if present (see below). Other
+ * OK, because we always copy the OID if present (see below). Other
* system columns may not.
*/
if (attno == ObjectIdAttributeNumber)
diff --git a/src/backend/access/nbtree/README b/src/backend/access/nbtree/README
index 5c0bc79..7055c24 100644
--- a/src/backend/access/nbtree/README
+++ b/src/backend/access/nbtree/README
@@ -470,7 +470,7 @@ not be seen under normal circumstances; only if insertion to the parent
has failed for some reason.
We flag the left page, even though it's the right page that's missing the
-downlink, beacuse it's more convenient to know already when following the
+downlink, because it's more convenient to know already when following the
right-link from the left page to the right page that it will need to have
its downlink inserted to the parent.
diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c
index a8f78d6..f6009e0 100644
--- a/src/backend/access/transam/xact.c
+++ b/src/backend/access/transam/xact.c
@@ -2005,7 +2005,7 @@ CommitTransaction(void)
if (!is_parallel_worker)
{
/*
- * We need to mark our XIDs as commited in pg_clog. This is where we
+ * We need to mark our XIDs as committed in pg_clog. This is where we
* durably commit.
*/
latestXid = RecordTransactionCommit();
@@ -2764,7 +2764,7 @@ CommitTransactionCommand(void)
/*
* Here we are in the middle of a transaction block but one of the
* commands caused an abort so we do nothing but remain in the
- * abort state. Eventually we will get a ROLLBACK comand.
+ * abort state. Eventually we will get a ROLLBACK command.
*/
case TBLOCK_ABORT:
case TBLOCK_SUBABORT:
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index c878f62..ea25cf0 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -832,7 +832,7 @@ SnapBuildAddCommittedTxn(SnapBuild *builder, TransactionId xid)
/*
* Remove knowledge about transactions we treat as committed that are smaller
- * than ->xmin. Those won't ever get checked via the ->commited array but via
+ * than ->xmin. Those won't ever get checked via the ->committed array but via
* the clog machinery, so we don't need to waste memory on them.
*/
static void
diff --git a/src/backend/tsearch/dict_synonym.c b/src/backend/tsearch/dict_synonym.c
index 26725a8..ee7e6cd 100644
--- a/src/backend/tsearch/dict_synonym.c
+++ b/src/backend/tsearch/dict_synonym.c
@@ -37,7 +37,7 @@ typedef struct
* Returns a pointer to the first character of the word, and a pointer
* to the next byte after the last character in the word (in *end).
* Character '*' at the end of word will not be threated as word
- * charater if flags is not null.
+ * character if flags is not null.
*/
static char *
findwrd(char *in, char **end, uint16 *flags)
diff --git a/src/backend/utils/adt/jsonfuncs.c b/src/backend/utils/adt/jsonfuncs.c
index 3dfdbf9..9987c73 100644
--- a/src/backend/utils/adt/jsonfuncs.c
+++ b/src/backend/utils/adt/jsonfuncs.c
@@ -3577,7 +3577,7 @@ IteratorConcat(JsonbIterator **it1, JsonbIterator **it2,
int level = 1;
/*
- * Append the all tokens from v1 to res, exept last WJB_END_OBJECT
+ * Append the all tokens from v1 to res, except last WJB_END_OBJECT
* (because res will not be finished yet).
*/
(void) pushJsonbValue(state, r1, NULL);
diff --git a/src/test/regress/expected/event_trigger.out b/src/test/regress/expected/event_trigger.out
index 24335df..e70c315 100644
--- a/src/test/regress/expected/event_trigger.out
+++ b/src/test/regress/expected/event_trigger.out
@@ -38,7 +38,7 @@ create event trigger regress_event_trigger2 on ddl_command_start
when tag in ('sandwhich')
execute procedure test_event_trigger();
ERROR: filter value "sandwhich" not recognized for filter variable "tag"
--- should fail, create skunkcabbage is not a valid comand tag
+-- should fail, create skunkcabbage is not a valid command tag
create event trigger regress_event_trigger2 on ddl_command_start
when tag in ('create table', 'create skunkcabbage')
execute procedure test_event_trigger();
diff --git a/src/test/regress/sql/event_trigger.sql b/src/test/regress/sql/event_trigger.sql
index 9f9646c..ec220fc 100644
--- a/src/test/regress/sql/event_trigger.sql
+++ b/src/test/regress/sql/event_trigger.sql
@@ -40,7 +40,7 @@ create event trigger regress_event_trigger2 on ddl_command_start
when tag in ('sandwhich')
execute procedure test_event_trigger();
--- should fail, create skunkcabbage is not a valid comand tag
+-- should fail, create skunkcabbage is not a valid command tag
create event trigger regress_event_trigger2 on ddl_command_start
when tag in ('create table', 'create skunkcabbage')
execute procedure test_event_trigger();
--
1.8.3.msysgit.0
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: fix typos
2015-05-17 11:46 fix typos Dmitriy Olshevskiy <olshevskiy87@bk.ru>
@ 2015-05-17 12:58 ` Magnus Hagander <magnus@hagander.net>
0 siblings, 0 replies; 27+ messages in thread
From: Magnus Hagander @ 2015-05-17 12:58 UTC (permalink / raw)
To: Dmitriy Olshevskiy <olshevskiy87@bk.ru>; +Cc: pgsql-hackers
On Sun, May 17, 2015 at 1:46 PM, Dmitriy Olshevskiy <olshevskiy87@bk.ru>
wrote:
> Hello. Please, see this patch with typos.
> Thank you.
Thanks, applied!
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
^ permalink raw reply [nested|flat] 27+ messages in thread
* Fix typos
@ 2019-08-01 12:24 Sehrope Sarkuni <sehrope@jackdb.com>
2019-08-02 01:06 ` Re: Fix typos Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 27+ messages in thread
From: Sehrope Sarkuni @ 2019-08-01 12:24 UTC (permalink / raw)
To: pgsql-hackers
Hi,
Attached fixes some typos for "serialise" => "serialize" and "materialise"
=> "materialize".
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
Attachments:
[text/x-patch] 0001-Fix-typos.patch (2.6K, ../../CAH7T-arisDyLzcFFtjSt2JDPw-8ysvOXBiJW9mRU5CQ_=3DfCA@mail.gmail.com/3-0001-Fix-typos.patch)
download | inline diff:
From 30d34d082120ac2c041a4ad45e9d6e31b0ea9c9d Mon Sep 17 00:00:00 2001
From: Sehrope Sarkuni <sehrope@jackdb.com>
Date: Thu, 1 Aug 2019 08:00:23 -0400
Subject: [PATCH] Fix typos
---
contrib/xml2/xpath.c | 2 +-
src/backend/access/transam/README | 4 ++--
src/backend/storage/buffer/bufmgr.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/xml2/xpath.c b/contrib/xml2/xpath.c
index 1e5b71d9a0..11749b6c47 100644
--- a/contrib/xml2/xpath.c
+++ b/contrib/xml2/xpath.c
@@ -573,7 +573,7 @@ xpath_table(PG_FUNCTION_ARGS)
errmsg("xpath_table must be called as a table function")));
/*
- * We want to materialise because it means that we don't have to carry
+ * We want to materialize because it means that we don't have to carry
* libxml2 parser state between invocations of this function
*/
if (!(rsinfo->allowedModes & SFRM_Materialize))
diff --git a/src/backend/access/transam/README b/src/backend/access/transam/README
index ad4083eb6b..49b6809c82 100644
--- a/src/backend/access/transam/README
+++ b/src/backend/access/transam/README
@@ -609,8 +609,8 @@ or more buffer locks be held concurrently, you must lock the pages in
appropriate order, and not release the locks until all the changes are done.
Note that we must only use PageSetLSN/PageGetLSN() when we know the action
-is serialised. Only Startup process may modify data blocks during recovery,
-so Startup process may execute PageGetLSN() without fear of serialisation
+is serialized. Only Startup process may modify data blocks during recovery,
+so Startup process may execute PageGetLSN() without fear of serialization
problems. All other processes must only call PageSet/GetLSN when holding
either an exclusive buffer lock or a shared lock plus buffer header lock,
or be writing the data block directly rather than through shared buffers
diff --git a/src/backend/storage/buffer/bufmgr.c b/src/backend/storage/buffer/bufmgr.c
index 6f3a402854..3d9e0a3488 100644
--- a/src/backend/storage/buffer/bufmgr.c
+++ b/src/backend/storage/buffer/bufmgr.c
@@ -3519,7 +3519,7 @@ MarkBufferDirtyHint(Buffer buffer, bool buffer_std)
/*
* Set the page LSN if we wrote a backup block. We aren't supposed
* to set this when only holding a share lock but as long as we
- * serialise it somehow we're OK. We choose to set LSN while
+ * serialize it somehow we're OK. We choose to set LSN while
* holding the buffer header lock, which causes any reader of an
* LSN who holds only a share lock to also obtain a buffer header
* lock before using PageGetLSN(), which is enforced in
--
2.17.1
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Fix typos
2019-08-01 12:24 Fix typos Sehrope Sarkuni <sehrope@jackdb.com>
@ 2019-08-02 01:06 ` Michael Paquier <michael@paquier.xyz>
2019-08-02 02:18 ` Re: Fix typos Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 27+ messages in thread
From: Michael Paquier @ 2019-08-02 01:06 UTC (permalink / raw)
To: Sehrope Sarkuni <sehrope@jackdb.com>; +Cc: pgsql-hackers
On Thu, Aug 01, 2019 at 08:24:17AM -0400, Sehrope Sarkuni wrote:
> Attached fixes some typos for "serialise" => "serialize" and "materialise"
> => "materialize".
These don't seem to be typos:
https://en.wiktionary.org/wiki/materialise
https://en.wiktionary.org/wiki/serialise
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../../20190802010603.GC1717@paquier.xyz/2-signature.asc)
download
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Fix typos
2019-08-01 12:24 Fix typos Sehrope Sarkuni <sehrope@jackdb.com>
2019-08-02 01:06 ` Re: Fix typos Michael Paquier <michael@paquier.xyz>
@ 2019-08-02 02:18 ` Tom Lane <tgl@sss.pgh.pa.us>
2019-08-02 03:01 ` Re: Fix typos Alvaro Herrera <alvherre@2ndquadrant.com>
2019-08-02 10:37 ` Re: Fix typos Sehrope Sarkuni <sehrope@jackdb.com>
0 siblings, 2 replies; 27+ messages in thread
From: Tom Lane @ 2019-08-02 02:18 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Sehrope Sarkuni <sehrope@jackdb.com>; pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> On Thu, Aug 01, 2019 at 08:24:17AM -0400, Sehrope Sarkuni wrote:
>> Attached fixes some typos for "serialise" => "serialize" and "materialise"
>> => "materialize".
> These don't seem to be typos:
> https://en.wiktionary.org/wiki/materialise
> https://en.wiktionary.org/wiki/serialise
It's British vs. American spelling. For the most part, Postgres
follows American spelling, but there's the odd Briticism here and
there. I'm not sure whether it's worth trying to standardize.
I think the most recent opinion on this was Munro's:
https://www.postgresql.org/message-id/CA+hUKGJz-pdMgWXroiwvN-aeG4-AjdWj3gWdQKOSa8g65spdVw@mail.gmail...
regards, tom lane
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Fix typos
2019-08-01 12:24 Fix typos Sehrope Sarkuni <sehrope@jackdb.com>
2019-08-02 01:06 ` Re: Fix typos Michael Paquier <michael@paquier.xyz>
2019-08-02 02:18 ` Re: Fix typos Tom Lane <tgl@sss.pgh.pa.us>
@ 2019-08-02 03:01 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2019-08-02 04:11 ` Re: Fix typos Michael Paquier <michael@paquier.xyz>
1 sibling, 1 reply; 27+ messages in thread
From: Alvaro Herrera @ 2019-08-02 03:01 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Michael Paquier <michael@paquier.xyz>; Sehrope Sarkuni <sehrope@jackdb.com>; pgsql-hackers
On 2019-Aug-01, Tom Lane wrote:
> It's British vs. American spelling. For the most part, Postgres
> follows American spelling, but there's the odd Briticism here and
> there. I'm not sure whether it's worth trying to standardize.
> I think the most recent opinion on this was Munro's:
>
> https://www.postgresql.org/message-id/CA+hUKGJz-pdMgWXroiwvN-aeG4-AjdWj3gWdQKOSa8g65spdVw@mail.gmail...
I think slight variations don't really detract from the value of the
product, and consider the odd variation a reminder of the diversity of
the project. I don't suggest that we purposefully introduce spelling
variations, or that we refrain from fixing ones that appear in code
we're changing, but I don't see the point in changing a line for the
sole reason of standardising the spelling of a word.
That said, I'm not a native English speaker.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Fix typos
2019-08-01 12:24 Fix typos Sehrope Sarkuni <sehrope@jackdb.com>
2019-08-02 01:06 ` Re: Fix typos Michael Paquier <michael@paquier.xyz>
2019-08-02 02:18 ` Re: Fix typos Tom Lane <tgl@sss.pgh.pa.us>
2019-08-02 03:01 ` Re: Fix typos Alvaro Herrera <alvherre@2ndquadrant.com>
@ 2019-08-02 04:11 ` Michael Paquier <michael@paquier.xyz>
2019-08-02 10:45 ` Re: Fix typos Sehrope Sarkuni <sehrope@jackdb.com>
0 siblings, 1 reply; 27+ messages in thread
From: Michael Paquier @ 2019-08-02 04:11 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Sehrope Sarkuni <sehrope@jackdb.com>; pgsql-hackers
On Thu, Aug 01, 2019 at 11:01:59PM -0400, Alvaro Herrera wrote:
> I think slight variations don't really detract from the value of the
> product, and consider the odd variation a reminder of the diversity of
> the project. I don't suggest that we purposefully introduce spelling
> variations, or that we refrain from fixing ones that appear in code
> we're changing, but I don't see the point in changing a line for the
> sole reason of standardising the spelling of a word.
Agreed. This always reminds me of ANALYZE vs. ANALYSE where we don't
actually document the latter :)
> That said, I'm not a native English speaker.
Neither am I.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../../20190802041107.GD19308@paquier.xyz/2-signature.asc)
download
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Fix typos
2019-08-01 12:24 Fix typos Sehrope Sarkuni <sehrope@jackdb.com>
2019-08-02 01:06 ` Re: Fix typos Michael Paquier <michael@paquier.xyz>
2019-08-02 02:18 ` Re: Fix typos Tom Lane <tgl@sss.pgh.pa.us>
2019-08-02 03:01 ` Re: Fix typos Alvaro Herrera <alvherre@2ndquadrant.com>
2019-08-02 04:11 ` Re: Fix typos Michael Paquier <michael@paquier.xyz>
@ 2019-08-02 10:45 ` Sehrope Sarkuni <sehrope@jackdb.com>
0 siblings, 0 replies; 27+ messages in thread
From: Sehrope Sarkuni @ 2019-08-02 10:45 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Alvaro Herrera <alvherre@2ndquadrant.com>; Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
On Fri, Aug 2, 2019 at 12:11 AM Michael Paquier <michael@paquier.xyz> wrote:
> On Thu, Aug 01, 2019 at 11:01:59PM -0400, Alvaro Herrera wrote:
> > I think slight variations don't really detract from the value of the
> > product, and consider the odd variation a reminder of the diversity of
> > the project. I don't suggest that we purposefully introduce spelling
> > variations, or that we refrain from fixing ones that appear in code
> > we're changing, but I don't see the point in changing a line for the
> > sole reason of standardising the spelling of a word.
>
> Agreed. This always reminds me of ANALYZE vs. ANALYSE where we don't
> actually document the latter :)
>
I didn't know about that. That's a fun one!
>
> > That said, I'm not a native English speaker.
>
> Neither am I.
>
I am. Consistency is nice but either reads fine to me. Only brought it up
as I didn't see many other usages so seemed out of place.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Fix typos
2019-08-01 12:24 Fix typos Sehrope Sarkuni <sehrope@jackdb.com>
2019-08-02 01:06 ` Re: Fix typos Michael Paquier <michael@paquier.xyz>
2019-08-02 02:18 ` Re: Fix typos Tom Lane <tgl@sss.pgh.pa.us>
@ 2019-08-02 10:37 ` Sehrope Sarkuni <sehrope@jackdb.com>
1 sibling, 0 replies; 27+ messages in thread
From: Sehrope Sarkuni @ 2019-08-02 10:37 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Michael Paquier <michael@paquier.xyz>; pgsql-hackers
On Thu, Aug 1, 2019 at 10:18 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> It's British vs. American spelling. For the most part, Postgres
> follows American spelling, but there's the odd Briticism here and
> there.
Thanks for the explanation. I thought that might be the case but didn't
find any other usages of "serialise" so was not sure.
> I'm not sure whether it's worth trying to standardize.
> I think the most recent opinion on this was Munro's:
>
>
> https://www.postgresql.org/message-id/CA+hUKGJz-pdMgWXroiwvN-aeG4-AjdWj3gWdQKOSa8g65spdVw@mail.gmail...
Either reads fine to me and the best rationale I can think of for going
with one spelling is to not have the same "fix" come up again.
If there is a desire to change this, attached is updated to include one
more instance of "materialise" and a change to the commit message to match
some similar ones I found in the past.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
Attachments:
[application/x-patch] v2-0001-Use-American-spelling-for-serialize-and-materalize.patch (3.3K, ../../CAH7T-apB97-5isHj=Bi+JSpaE9_L+pH7gPr=Mi-ZgR7bdpr7rQ@mail.gmail.com/3-v2-0001-Use-American-spelling-for-serialize-and-materalize.patch)
download | inline diff:
From 20c018b9350cb17e87930cebb66b715bc4b9fcf4 Mon Sep 17 00:00:00 2001
From: Sehrope Sarkuni <sehrope@jackdb.com>
Date: Fri, 2 Aug 2019 05:58:35 -0400
Subject: [PATCH] Use American spelling for "serialize" and "materalize"
---
contrib/pgstattuple/pgstatapprox.c | 2 +-
contrib/xml2/xpath.c | 2 +-
src/backend/access/transam/README | 4 ++--
src/backend/storage/buffer/bufmgr.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/contrib/pgstattuple/pgstatapprox.c b/contrib/pgstattuple/pgstatapprox.c
index 636c8d40ac..83b3270554 100644
--- a/contrib/pgstattuple/pgstatapprox.c
+++ b/contrib/pgstattuple/pgstatapprox.c
@@ -278,7 +278,7 @@ pgstattuple_approx_internal(Oid relid, FunctionCallInfo fcinfo)
errmsg("cannot access temporary tables of other sessions")));
/*
- * We support only ordinary relations and materialised views, because we
+ * We support only ordinary relations and materialized views, because we
* depend on the visibility map and free space map for our estimates about
* unscanned pages.
*/
diff --git a/contrib/xml2/xpath.c b/contrib/xml2/xpath.c
index 1e5b71d9a0..11749b6c47 100644
--- a/contrib/xml2/xpath.c
+++ b/contrib/xml2/xpath.c
@@ -573,7 +573,7 @@ xpath_table(PG_FUNCTION_ARGS)
errmsg("xpath_table must be called as a table function")));
/*
- * We want to materialise because it means that we don't have to carry
+ * We want to materialize because it means that we don't have to carry
* libxml2 parser state between invocations of this function
*/
if (!(rsinfo->allowedModes & SFRM_Materialize))
diff --git a/src/backend/access/transam/README b/src/backend/access/transam/README
index ad4083eb6b..49b6809c82 100644
--- a/src/backend/access/transam/README
+++ b/src/backend/access/transam/README
@@ -609,8 +609,8 @@ or more buffer locks be held concurrently, you must lock the pages in
appropriate order, and not release the locks until all the changes are done.
Note that we must only use PageSetLSN/PageGetLSN() when we know the action
-is serialised. Only Startup process may modify data blocks during recovery,
-so Startup process may execute PageGetLSN() without fear of serialisation
+is serialized. Only Startup process may modify data blocks during recovery,
+so Startup process may execute PageGetLSN() without fear of serialization
problems. All other processes must only call PageSet/GetLSN when holding
either an exclusive buffer lock or a shared lock plus buffer header lock,
or be writing the data block directly rather than through shared buffers
diff --git a/src/backend/storage/buffer/bufmgr.c b/src/backend/storage/buffer/bufmgr.c
index 6f3a402854..3d9e0a3488 100644
--- a/src/backend/storage/buffer/bufmgr.c
+++ b/src/backend/storage/buffer/bufmgr.c
@@ -3519,7 +3519,7 @@ MarkBufferDirtyHint(Buffer buffer, bool buffer_std)
/*
* Set the page LSN if we wrote a backup block. We aren't supposed
* to set this when only holding a share lock but as long as we
- * serialise it somehow we're OK. We choose to set LSN while
+ * serialize it somehow we're OK. We choose to set LSN while
* holding the buffer header lock, which causes any reader of an
* LSN who holds only a share lock to also obtain a buffer header
* lock before using PageGetLSN(), which is enforced in
--
2.17.1
^ permalink raw reply [nested|flat] 27+ messages in thread
* [PATCH 1/3] Fix typos
@ 2021-04-28 08:23 Kyotaro Horiguchi <horikyota.ntt@gmail.com>
0 siblings, 0 replies; 27+ messages in thread
From: Kyotaro Horiguchi @ 2021-04-28 08:23 UTC (permalink / raw)
---
src/backend/commands/operatorcmds.c | 2 +-
src/backend/utils/adt/multirangetypes.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/backend/commands/operatorcmds.c b/src/backend/commands/operatorcmds.c
index 809043c5d1..ba456c4dd1 100644
--- a/src/backend/commands/operatorcmds.c
+++ b/src/backend/commands/operatorcmds.c
@@ -300,7 +300,7 @@ ValidateRestrictionEstimator(List *restrictionName)
}
/*
- * Look up a join estimator function ny name, and verify that it has the
+ * Look up a join estimator function by name, and verify that it has the
* correct signature and we have the permissions to attach it to an
* operator.
*/
diff --git a/src/backend/utils/adt/multirangetypes.c b/src/backend/utils/adt/multirangetypes.c
index 0b81649779..2583ddeedf 100644
--- a/src/backend/utils/adt/multirangetypes.c
+++ b/src/backend/utils/adt/multirangetypes.c
@@ -1417,7 +1417,7 @@ multirange_intersect_agg_transfn(PG_FUNCTION_ARGS)
if (!type_is_multirange(mltrngtypoid))
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
- errmsg("range_intersect_agg must be called with a multirange")));
+ errmsg("multirange_intersect_agg must be called with a multirange")));
typcache = multirange_get_typcache(fcinfo, mltrngtypoid);
--
2.27.0
----Next_Part(Wed_Apr_28_17_36_33_2021_627)--
Content-Type: Text/X-Patch; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="0002-Consolidate-substantially-same-messages.patch"
^ permalink raw reply [nested|flat] 27+ messages in thread
* Fix typos
@ 2021-11-29 01:01 qianglj.fnst@fujitsu.com <qianglj.fnst@fujitsu.com>
2021-11-30 02:09 ` Re: Fix typos Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 27+ messages in thread
From: qianglj.fnst@fujitsu.com @ 2021-11-29 01:01 UTC (permalink / raw)
To: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
Hi,
I found several typos in comments and README. See patch attached.
Best regards,
Lingjie Qiang
Attachments:
[application/octet-stream] 0001-fix-typos.patch (1.9K, ../../OSAPR01MB71654E773F62AC88DC1FC8CC80669@OSAPR01MB7165.jpnprd01.prod.outlook.com/3-0001-fix-typos.patch)
download | inline diff:
diff --git a/src/backend/storage/lmgr/README b/src/backend/storage/lmgr/README
index c96cc7b7c5..d08ec6c402 100644
--- a/src/backend/storage/lmgr/README
+++ b/src/backend/storage/lmgr/README
@@ -692,7 +692,7 @@ User Locks (Advisory Locks)
User locks are handled totally on the application side as long term
cooperative locks which may extend beyond the normal transaction boundaries.
Their purpose is to indicate to an application that someone is `working'
-on an item. So it is possible to put an user lock on a tuple's oid,
+on an item. So it is possible to put a user lock on a tuple's oid,
retrieve the tuple, work on it for an hour and then update it and remove
the lock. While the lock is active other clients can still read and write
the tuple but they can be aware that it has been locked at the application
diff --git a/src/backend/utils/adt/pg_locale.c b/src/backend/utils/adt/pg_locale.c
index 453af401ca..cc2ab95535 100644
--- a/src/backend/utils/adt/pg_locale.c
+++ b/src/backend/utils/adt/pg_locale.c
@@ -1068,7 +1068,7 @@ get_iso_localename(const char *winlocname)
LOCALE_NAME_MAX_LENGTH);
/*
- * If the lc_messages is already an Unix-style string, we have a direct
+ * If the lc_messages is already a Unix-style string, we have a direct
* match with LOCALE_SNAME, e.g. en-US, en_US.
*/
ret_val = GetLocaleInfoEx(wc_locale_name, LOCALE_SNAME, (LPWSTR) &buffer,
diff --git a/src/include/access/attnum.h b/src/include/access/attnum.h
index 0c43e26c2d..c80bdd245a 100644
--- a/src/include/access/attnum.h
+++ b/src/include/access/attnum.h
@@ -36,7 +36,7 @@ typedef int16 AttrNumber;
/*
* AttrNumberIsForUserDefinedAttr
- * True iff the attribute number corresponds to an user defined attribute.
+ * True iff the attribute number corresponds to a user defined attribute.
*/
#define AttrNumberIsForUserDefinedAttr(attributeNumber) \
((bool) ((attributeNumber) > 0))
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: Fix typos
2021-11-29 01:01 Fix typos qianglj.fnst@fujitsu.com <qianglj.fnst@fujitsu.com>
@ 2021-11-30 02:09 ` Michael Paquier <michael@paquier.xyz>
0 siblings, 0 replies; 27+ messages in thread
From: Michael Paquier @ 2021-11-30 02:09 UTC (permalink / raw)
To: qianglj.fnst@fujitsu.com <qianglj.fnst@fujitsu.com>; +Cc: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
On Mon, Nov 29, 2021 at 01:01:55AM +0000, qianglj.fnst@fujitsu.com wrote:
> I found several typos in comments and README. See patch attached.
Thanks, fixed.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../../YaWH2BGSWLF6dljG@paquier.xyz/2-signature.asc)
download
^ permalink raw reply [nested|flat] 27+ messages in thread
* fix typos
@ 2022-08-01 18:04 Erik Rijkers <er@xs4all.nl>
2022-08-01 18:11 ` Re: fix typos Justin Pryzby <pryzby@telsasoft.com>
2022-08-02 05:28 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
0 siblings, 2 replies; 27+ messages in thread
From: Erik Rijkers @ 2022-08-01 18:04 UTC (permalink / raw)
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Recent typos...
--- ./doc/src/sgml/ref/drop_extension.sgml.orig 2022-08-01 19:38:18.249729884 +0200
+++ ./doc/src/sgml/ref/drop_extension.sgml 2022-08-01 19:40:33.312359069 +0200
@@ -32,7 +32,7 @@
<command>DROP EXTENSION</command> removes extensions from the database.
Dropping an extension causes its component objects, and other explicitly
dependent routines (see <xref linkend="sql-alterroutine"/>,
- the depends on extension action), to be dropped as well.
+ that depend on extension action), to be dropped as well.
</para>
<para>
@@ -80,8 +80,8 @@
<listitem>
<para>
This option prevents the specified extensions from being dropped
- if there exists non-extension-member objects that depends on any
- the extensions. This is the default.
+ if there exist non-extension-member objects that depend on any
+ of the extensions. This is the default.
</para>
</listitem>
</varlistentry>
--- ./doc/src/sgml/ref/psql-ref.sgml.orig 2022-08-01 19:58:21.000644788 +0200
+++ ./doc/src/sgml/ref/psql-ref.sgml 2022-08-01 19:59:00.417285655 +0200
@@ -2864,7 +2864,7 @@
</para>
<para>
- <literal>page</literal>: truncate the the header line at the terminal
+ <literal>page</literal>: truncate the header line at the terminal
width.
</para>
Attachments:
[text/plain] drop_extension.sgml.diff.20220801.txt (948B, ../../b79bfeff-d0e3-29a3-2576-0e325848dede@xs4all.nl/2-drop_extension.sgml.diff.20220801.txt)
download | inline:
--- ./doc/src/sgml/ref/drop_extension.sgml.orig 2022-08-01 19:38:18.249729884 +0200
+++ ./doc/src/sgml/ref/drop_extension.sgml 2022-08-01 19:40:33.312359069 +0200
@@ -32,7 +32,7 @@
<command>DROP EXTENSION</command> removes extensions from the database.
Dropping an extension causes its component objects, and other explicitly
dependent routines (see <xref linkend="sql-alterroutine"/>,
- the depends on extension action), to be dropped as well.
+ that depend on extension action), to be dropped as well.
</para>
<para>
@@ -80,8 +80,8 @@
<listitem>
<para>
This option prevents the specified extensions from being dropped
- if there exists non-extension-member objects that depends on any
- the extensions. This is the default.
+ if there exist non-extension-member objects that depend on any
+ of the extensions. This is the default.
</para>
</listitem>
</varlistentry>
[text/plain] psql-ref.sgml.diff.20220801.txt (412B, ../../b79bfeff-d0e3-29a3-2576-0e325848dede@xs4all.nl/3-psql-ref.sgml.diff.20220801.txt)
download | inline:
--- ./doc/src/sgml/ref/psql-ref.sgml.orig 2022-08-01 19:58:21.000644788 +0200
+++ ./doc/src/sgml/ref/psql-ref.sgml 2022-08-01 19:59:00.417285655 +0200
@@ -2864,7 +2864,7 @@
</para>
<para>
- <literal>page</literal>: truncate the the header line at the terminal
+ <literal>page</literal>: truncate the header line at the terminal
width.
</para>
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: fix typos
2022-08-01 18:04 fix typos Erik Rijkers <er@xs4all.nl>
@ 2022-08-01 18:11 ` Justin Pryzby <pryzby@telsasoft.com>
2022-08-02 05:52 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
2022-08-04 10:21 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
1 sibling, 2 replies; 27+ messages in thread
From: Justin Pryzby @ 2022-08-01 18:11 UTC (permalink / raw)
To: Erik Rijkers <er@xs4all.nl>; +Cc: pgsql-hackers@lists.postgresql.org
On Mon, Aug 01, 2022 at 08:04:54PM +0200, Erik Rijkers wrote:
> Recent typos...
LGTM, thanks.
Here are some others I've been sitting on, mostly in .c files.
--
Justin
Attachments:
[text/x-diff] 0001-typos.patch (2.7K, ../../20220801181136.GJ15006@telsasoft.com/2-0001-typos.patch)
download | inline diff:
From 19f320438476aff2773440447f167d06051a0a47 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Tue, 5 Jul 2022 14:12:26 -0500
Subject: [PATCH 1/4] typos
---
doc/src/sgml/brin.sgml | 2 +-
src/backend/commands/dbcommands.c | 6 +++---
src/include/replication/reorderbuffer.h | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/brin.sgml b/doc/src/sgml/brin.sgml
index 4ee8908b65a..71697155d7c 100644
--- a/doc/src/sgml/brin.sgml
+++ b/doc/src/sgml/brin.sgml
@@ -75,7 +75,7 @@
summarized will cause the summary information to be updated with data
from the new tuples.
When a new page is created that does not fall within the last
- summarized range, the range that the new page belongs into
+ summarized range, the range that the new page belongs to
does not automatically acquire a summary tuple;
those tuples remain unsummarized until a summarization run is
invoked later, creating the initial summary for that range.
diff --git a/src/backend/commands/dbcommands.c b/src/backend/commands/dbcommands.c
index 7bc53f3a0bb..9f990a8d68f 100644
--- a/src/backend/commands/dbcommands.c
+++ b/src/backend/commands/dbcommands.c
@@ -188,7 +188,7 @@ CreateDatabaseUsingWalLog(Oid src_dboid, Oid dst_dboid,
/*
* If the relation is from the source db's default tablespace then we
- * need to create it in the destinations db's default tablespace.
+ * need to create it in the destination db's default tablespace.
* Otherwise, we need to create in the same tablespace as it is in the
* source database.
*/
@@ -1351,8 +1351,8 @@ createdb(ParseState *pstate, const CreatedbStmt *stmt)
/*
* If we're going to be reading data for the to-be-created database into
* shared_buffers, take a lock on it. Nobody should know that this
- * database exists yet, but it's good to maintain the invariant that a
- * lock an AccessExclusiveLock on the database is sufficient to drop all
+ * database exists yet, but it's good to maintain the invariant that an
+ * AccessExclusiveLock on the database is sufficient to drop all
* of its buffers without worrying about more being read later.
*
* Note that we need to do this before entering the
diff --git a/src/include/replication/reorderbuffer.h b/src/include/replication/reorderbuffer.h
index d109d0baede..2c9206ace41 100644
--- a/src/include/replication/reorderbuffer.h
+++ b/src/include/replication/reorderbuffer.h
@@ -262,7 +262,7 @@ typedef struct ReorderBufferTXN
* aborted. This can be a
* * plain commit record
* * plain commit record, of a parent transaction
- * * prepared tansaction
+ * * prepared transaction
* * prepared transaction commit
* * plain abort record
* * prepared transaction abort
--
2.17.1
[text/x-diff] 0002-fix-whitespace.patch (1.3K, ../../20220801181136.GJ15006@telsasoft.com/3-0002-fix-whitespace.patch)
download | inline diff:
From 57b1a6001b2910c9a8002e72f22391255e8b8bb9 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Sat, 23 Jul 2022 15:10:01 -0500
Subject: [PATCH 2/4] fix whitespace
weird since c91560defc57f89f7e88632ea14ae77b5cec78ee
---
src/backend/utils/cache/inval.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/backend/utils/cache/inval.c b/src/backend/utils/cache/inval.c
index eb5782f82a4..c0e33c0f177 100644
--- a/src/backend/utils/cache/inval.c
+++ b/src/backend/utils/cache/inval.c
@@ -9,8 +9,8 @@
* consider that it is *still valid* so long as we are in the same command,
* ie, until the next CommandCounterIncrement() or transaction commit.
* (See access/heap/heapam_visibility.c, and note that system catalogs are
- * generally scanned under the most current snapshot available, rather than
- * the transaction snapshot.) At the command boundary, the old tuple stops
+ * generally scanned under the most current snapshot available, rather than
+ * the transaction snapshot.) At the command boundary, the old tuple stops
* being valid and the new version, if any, becomes valid. Therefore,
* we cannot simply flush a tuple from the system caches during heap_update()
* or heap_delete(). The tuple is still good at that point; what's more,
--
2.17.1
[text/x-diff] 0003-f-newline.patch (710B, ../../20220801181136.GJ15006@telsasoft.com/4-0003-f-newline.patch)
download | inline diff:
From 6fc057ae26567f39b85902933e4eddc9cbd9c915 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Tue, 26 Jul 2022 18:34:08 -0500
Subject: [PATCH 3/4] f!newline
---
src/backend/commands/explain.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/backend/commands/explain.c b/src/backend/commands/explain.c
index e29c2ae206f..e078456b191 100644
--- a/src/backend/commands/explain.c
+++ b/src/backend/commands/explain.c
@@ -3284,7 +3284,6 @@ show_hashagg_info(AggState *aggstate, ExplainState *es)
if (es->format != EXPLAIN_FORMAT_TEXT)
{
-
if (es->costs)
ExplainPropertyInteger("Planned Partitions", NULL,
aggstate->hash_planned_partitions, es);
--
2.17.1
[text/x-diff] 0004-print-oids-with-u.patch (1.5K, ../../20220801181136.GJ15006@telsasoft.com/5-0004-print-oids-with-u.patch)
download | inline diff:
From 050de51a3018ed4e609a9f77385708af1692b720 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Sun, 31 Jul 2022 00:30:53 -0500
Subject: [PATCH 4/4] print oids with %u
---
src/backend/replication/logical/origin.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/backend/replication/logical/origin.c b/src/backend/replication/logical/origin.c
index c72ad6b93de..ac12f5e26cb 100644
--- a/src/backend/replication/logical/origin.c
+++ b/src/backend/replication/logical/origin.c
@@ -364,7 +364,7 @@ restart:
if (nowait)
ereport(ERROR,
(errcode(ERRCODE_OBJECT_IN_USE),
- errmsg("could not drop replication origin with OID %d, in use by PID %d",
+ errmsg("could not drop replication origin with OID %u, in use by PID %d",
state->roident,
state->acquired_by)));
@@ -937,7 +937,7 @@ replorigin_advance(RepOriginId node,
{
ereport(ERROR,
(errcode(ERRCODE_OBJECT_IN_USE),
- errmsg("replication origin with OID %d is already active for PID %d",
+ errmsg("replication origin with OID %u is already active for PID %d",
replication_state->roident,
replication_state->acquired_by)));
}
@@ -1126,7 +1126,7 @@ replorigin_session_setup(RepOriginId node)
{
ereport(ERROR,
(errcode(ERRCODE_OBJECT_IN_USE),
- errmsg("replication origin with OID %d is already active for PID %d",
+ errmsg("replication origin with OID %u is already active for PID %d",
curstate->roident, curstate->acquired_by)));
}
--
2.17.1
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: fix typos
2022-08-01 18:04 fix typos Erik Rijkers <er@xs4all.nl>
2022-08-01 18:11 ` Re: fix typos Justin Pryzby <pryzby@telsasoft.com>
@ 2022-08-02 05:52 ` John Naylor <john.naylor@enterprisedb.com>
1 sibling, 0 replies; 27+ messages in thread
From: John Naylor @ 2022-08-02 05:52 UTC (permalink / raw)
To: Justin Pryzby <pryzby@telsasoft.com>; +Cc: Erik Rijkers <er@xs4all.nl>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Tue, Aug 2, 2022 at 1:11 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
>
> Here are some others I've been sitting on, mostly in .c files.
0002:
weird since c91560defc57f89f7e88632ea14ae77b5cec78ee
It was weird long before that, maybe we should instead change most of those
tabs in the top comment to single space, as is customary? The rest LGTM.
--
John Naylor
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: fix typos
2022-08-01 18:04 fix typos Erik Rijkers <er@xs4all.nl>
2022-08-01 18:11 ` Re: fix typos Justin Pryzby <pryzby@telsasoft.com>
@ 2022-08-04 10:21 ` John Naylor <john.naylor@enterprisedb.com>
2022-08-04 13:41 ` Re: fix typos Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 27+ messages in thread
From: John Naylor @ 2022-08-04 10:21 UTC (permalink / raw)
To: Justin Pryzby <pryzby@telsasoft.com>; +Cc: Erik Rijkers <er@xs4all.nl>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Tue, Aug 2, 2022 at 1:11 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
>
> On Mon, Aug 01, 2022 at 08:04:54PM +0200, Erik Rijkers wrote:
> > Recent typos...
>
> LGTM, thanks.
>
> Here are some others I've been sitting on, mostly in .c files.
I pushed Robert's suggestion, then pushed the rest of Erik's changes and
two of Justin's. For Justin's 0004:
--- a/src/backend/replication/logical/origin.c
+++ b/src/backend/replication/logical/origin.c
@@ -364,7 +364,7 @@ restart:
if (nowait)
ereport(ERROR,
(errcode(ERRCODE_OBJECT_IN_USE),
- errmsg("could not drop replication origin with OID %d, in use by PID %d",
+ errmsg("could not drop replication origin with OID %u, in use by PID %d",
RepOriginId is a typedef for uint16, so this can't print the wrong answer,
but it is inconsistent with other uses. So it seems we don't need to
backpatch this one?
For patch 0002, the whitespace issue in the top comment in inval.c, I'm
inclined to just change all the out-of-place tabs in a single commit, so we
can add that to the list of whitespace commits.
--
John Naylor
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: fix typos
2022-08-01 18:04 fix typos Erik Rijkers <er@xs4all.nl>
2022-08-01 18:11 ` Re: fix typos Justin Pryzby <pryzby@telsasoft.com>
2022-08-04 10:21 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
@ 2022-08-04 13:41 ` Tom Lane <tgl@sss.pgh.pa.us>
2022-08-05 04:47 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
0 siblings, 1 reply; 27+ messages in thread
From: Tom Lane @ 2022-08-04 13:41 UTC (permalink / raw)
To: John Naylor <john.naylor@enterprisedb.com>; +Cc: Justin Pryzby <pryzby@telsasoft.com>; Erik Rijkers <er@xs4all.nl>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
John Naylor <john.naylor@enterprisedb.com> writes:
> On Tue, Aug 2, 2022 at 1:11 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
> ereport(ERROR,
> (errcode(ERRCODE_OBJECT_IN_USE),
> - errmsg("could not drop replication origin with OID %d, in use by PID %d",
> + errmsg("could not drop replication origin with OID %u, in use by PID %d",
> RepOriginId is a typedef for uint16, so this can't print the wrong answer,
> but it is inconsistent with other uses. So it seems we don't need to
> backpatch this one?
Um ... if it's int16, then it can't be an OID, so I'd say this message has
far worse problems than %d vs %u. It should not use that terminology.
regards, tom lane
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: fix typos
2022-08-01 18:04 fix typos Erik Rijkers <er@xs4all.nl>
2022-08-01 18:11 ` Re: fix typos Justin Pryzby <pryzby@telsasoft.com>
2022-08-04 10:21 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
2022-08-04 13:41 ` Re: fix typos Tom Lane <tgl@sss.pgh.pa.us>
@ 2022-08-05 04:47 ` John Naylor <john.naylor@enterprisedb.com>
2022-08-12 06:59 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
0 siblings, 1 reply; 27+ messages in thread
From: John Naylor @ 2022-08-05 04:47 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Justin Pryzby <pryzby@telsasoft.com>; Erik Rijkers <er@xs4all.nl>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Thu, Aug 4, 2022 at 8:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> John Naylor <john.naylor@enterprisedb.com> writes:
> > RepOriginId is a typedef for uint16, so this can't print the wrong
answer,
> > but it is inconsistent with other uses. So it seems we don't need to
> > backpatch this one?
>
> Um ... if it's int16, then it can't be an OID, so I'd say this message has
> far worse problems than %d vs %u. It should not use that terminology.
The catalog has the following. Since it's not a real oid, maybe this column
should be rethought?
CATALOG(pg_replication_origin,6000,ReplicationOriginRelationId)
BKI_SHARED_RELATION
{
/*
* Locally known id that get included into WAL.
*
* This should never leave the system.
*
* Needs to fit into an uint16, so we don't waste too much space in WAL
* records. For this reason we don't use a normal Oid column here, since
* we need to handle allocation of new values manually.
*/
Oid roident;
[...]
--
John Naylor
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: fix typos
2022-08-01 18:04 fix typos Erik Rijkers <er@xs4all.nl>
2022-08-01 18:11 ` Re: fix typos Justin Pryzby <pryzby@telsasoft.com>
2022-08-04 10:21 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
2022-08-04 13:41 ` Re: fix typos Tom Lane <tgl@sss.pgh.pa.us>
2022-08-05 04:47 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
@ 2022-08-12 06:59 ` John Naylor <john.naylor@enterprisedb.com>
2022-08-12 12:04 ` Re: fix typos Euler Taveira <euler@eulerto.com>
2022-08-12 13:55 ` Re: fix typos Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 27+ messages in thread
From: John Naylor @ 2022-08-12 06:59 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Justin Pryzby <pryzby@telsasoft.com>; Erik Rijkers <er@xs4all.nl>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
I wrote:
> On Thu, Aug 4, 2022 at 8:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > John Naylor <john.naylor@enterprisedb.com> writes:
>
> > > RepOriginId is a typedef for uint16, so this can't print the wrong answer,
> > > but it is inconsistent with other uses. So it seems we don't need to
> > > backpatch this one?
> >
> > Um ... if it's int16, then it can't be an OID, so I'd say this message has
> > far worse problems than %d vs %u. It should not use that terminology.
>
> The catalog has the following. Since it's not a real oid, maybe this column should be rethought?
This is really a straw-man proposal, since I'm not volunteering to do
the work, or suggest anybody else should do the same. That being the
case, it seems we should just go ahead with Justin's patch for
consistency. Possibly we could also change the messages to say "ID"?
> CATALOG(pg_replication_origin,6000,ReplicationOriginRelationId) BKI_SHARED_RELATION
> {
> /*
> * Locally known id that get included into WAL.
> *
> * This should never leave the system.
> *
> * Needs to fit into an uint16, so we don't waste too much space in WAL
> * records. For this reason we don't use a normal Oid column here, since
> * we need to handle allocation of new values manually.
> */
> Oid roident;
--
John Naylor
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: fix typos
2022-08-01 18:04 fix typos Erik Rijkers <er@xs4all.nl>
2022-08-01 18:11 ` Re: fix typos Justin Pryzby <pryzby@telsasoft.com>
2022-08-04 10:21 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
2022-08-04 13:41 ` Re: fix typos Tom Lane <tgl@sss.pgh.pa.us>
2022-08-05 04:47 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
2022-08-12 06:59 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
@ 2022-08-12 12:04 ` Euler Taveira <euler@eulerto.com>
1 sibling, 0 replies; 27+ messages in thread
From: Euler Taveira @ 2022-08-12 12:04 UTC (permalink / raw)
To: John Naylor <john.naylor@enterprisedb.com>; Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Justin Pryzby <pryzby@telsasoft.com>; Erik Rijkers <er@xs4all.nl>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Fri, Aug 12, 2022, at 3:59 AM, John Naylor wrote:
> This is really a straw-man proposal, since I'm not volunteering to do
> the work, or suggest anybody else should do the same. That being the
> case, it seems we should just go ahead with Justin's patch for
> consistency. Possibly we could also change the messages to say "ID"?
... or say
could not drop replication origin %u, in use by PID %d
AFAICS there is no "with ID" but there is "with identifier". I personally
prefer to omit these additional words; it seems clear without them.
--
Euler Taveira
EDB https://www.enterprisedb.com/
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: fix typos
2022-08-01 18:04 fix typos Erik Rijkers <er@xs4all.nl>
2022-08-01 18:11 ` Re: fix typos Justin Pryzby <pryzby@telsasoft.com>
2022-08-04 10:21 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
2022-08-04 13:41 ` Re: fix typos Tom Lane <tgl@sss.pgh.pa.us>
2022-08-05 04:47 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
2022-08-12 06:59 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
@ 2022-08-12 13:55 ` Tom Lane <tgl@sss.pgh.pa.us>
2022-08-16 01:48 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
1 sibling, 1 reply; 27+ messages in thread
From: Tom Lane @ 2022-08-12 13:55 UTC (permalink / raw)
To: John Naylor <john.naylor@enterprisedb.com>; +Cc: Justin Pryzby <pryzby@telsasoft.com>; Erik Rijkers <er@xs4all.nl>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
John Naylor <john.naylor@enterprisedb.com> writes:
> This is really a straw-man proposal, since I'm not volunteering to do
> the work, or suggest anybody else should do the same. That being the
> case, it seems we should just go ahead with Justin's patch for
> consistency. Possibly we could also change the messages to say "ID"?
I'd be content if we change the user-facing messages (and documentation
if any) to say "ID" not "OID".
regards, tom lane
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: fix typos
2022-08-01 18:04 fix typos Erik Rijkers <er@xs4all.nl>
2022-08-01 18:11 ` Re: fix typos Justin Pryzby <pryzby@telsasoft.com>
2022-08-04 10:21 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
2022-08-04 13:41 ` Re: fix typos Tom Lane <tgl@sss.pgh.pa.us>
2022-08-05 04:47 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
2022-08-12 06:59 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
2022-08-12 13:55 ` Re: fix typos Tom Lane <tgl@sss.pgh.pa.us>
@ 2022-08-16 01:48 ` John Naylor <john.naylor@enterprisedb.com>
2022-08-18 02:11 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
0 siblings, 1 reply; 27+ messages in thread
From: John Naylor @ 2022-08-16 01:48 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Justin Pryzby <pryzby@telsasoft.com>; Erik Rijkers <er@xs4all.nl>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Fri, Aug 12, 2022 at 8:55 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> John Naylor <john.naylor@enterprisedb.com> writes:
> > This is really a straw-man proposal, since I'm not volunteering to do
> > the work, or suggest anybody else should do the same. That being the
> > case, it seems we should just go ahead with Justin's patch for
> > consistency. Possibly we could also change the messages to say "ID"?
>
> I'd be content if we change the user-facing messages (and documentation
> if any) to say "ID" not "OID".
The documentation has both, so it makes sense to standardize on "ID".
The messages all had oid/OID, which I changed in the attached. I think
I got all the places.
I'm thinking it's not wrong enough to confuse people, but consistency
is good, so backpatch to v15 and no further. Does anyone want to make
a case otherwise?
--
John Naylor
EDB: http://www.enterprisedb.com
Attachments:
[text/x-patch] v1-consistently-refer-to-roident-as-ID-in-messages-and-docs.patch (4.1K, ../../CAFBsxsHeOC+ipxHJkd71EOg+PnKdA+KAzeGwEK9_1t7pvA2buA@mail.gmail.com/2-v1-consistently-refer-to-roident-as-ID-in-messages-and-docs.patch)
download | inline diff:
diff --git a/doc/src/sgml/replication-origins.sgml b/doc/src/sgml/replication-origins.sgml
index 7e02c4605b..bb0fb624d2 100644
--- a/doc/src/sgml/replication-origins.sgml
+++ b/doc/src/sgml/replication-origins.sgml
@@ -27,12 +27,12 @@
</para>
<para>
- Replication origins have just two properties, a name and an OID. The name,
+ Replication origins have just two properties, a name and an ID. The name,
which is what should be used to refer to the origin across systems, is
free-form <type>text</type>. It should be used in a way that makes conflicts
between replication origins created by different replication solutions
unlikely; e.g., by prefixing the replication solution's name to it.
- The OID is used only to avoid having to store the long version
+ The ID is used only to avoid having to store the long version
in situations where space efficiency is important. It should never be shared
across systems.
</para>
diff --git a/src/backend/replication/logical/origin.c b/src/backend/replication/logical/origin.c
index c72ad6b93d..9eb97fac58 100644
--- a/src/backend/replication/logical/origin.c
+++ b/src/backend/replication/logical/origin.c
@@ -328,7 +328,7 @@ replorigin_create(const char *roname)
if (tuple == NULL)
ereport(ERROR,
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
- errmsg("could not find free replication origin OID")));
+ errmsg("could not find free replication origin ID")));
heap_freetuple(tuple);
return roident;
@@ -364,7 +364,7 @@ restart:
if (nowait)
ereport(ERROR,
(errcode(ERRCODE_OBJECT_IN_USE),
- errmsg("could not drop replication origin with OID %d, in use by PID %d",
+ errmsg("could not drop replication origin with ID %u, in use by PID %d",
state->roident,
state->acquired_by)));
@@ -408,7 +408,7 @@ restart:
*/
tuple = SearchSysCache1(REPLORIGIDENT, ObjectIdGetDatum(roident));
if (!HeapTupleIsValid(tuple))
- elog(ERROR, "cache lookup failed for replication origin with oid %u",
+ elog(ERROR, "cache lookup failed for replication origin with ID %u",
roident);
CatalogTupleDelete(rel, &tuple->t_self);
@@ -485,7 +485,7 @@ replorigin_by_oid(RepOriginId roident, bool missing_ok, char **roname)
if (!missing_ok)
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
- errmsg("replication origin with OID %u does not exist",
+ errmsg("replication origin with ID %u does not exist",
roident)));
return false;
@@ -937,7 +937,7 @@ replorigin_advance(RepOriginId node,
{
ereport(ERROR,
(errcode(ERRCODE_OBJECT_IN_USE),
- errmsg("replication origin with OID %d is already active for PID %d",
+ errmsg("replication origin with ID %u is already active for PID %d",
replication_state->roident,
replication_state->acquired_by)));
}
@@ -948,7 +948,7 @@ replorigin_advance(RepOriginId node,
if (replication_state == NULL && free_state == NULL)
ereport(ERROR,
(errcode(ERRCODE_CONFIGURATION_LIMIT_EXCEEDED),
- errmsg("could not find free replication state slot for replication origin with OID %u",
+ errmsg("could not find free replication state slot for replication origin with ID %u",
node),
errhint("Increase max_replication_slots and try again.")));
@@ -1126,7 +1126,7 @@ replorigin_session_setup(RepOriginId node)
{
ereport(ERROR,
(errcode(ERRCODE_OBJECT_IN_USE),
- errmsg("replication origin with OID %d is already active for PID %d",
+ errmsg("replication origin with ID %u is already active for PID %d",
curstate->roident, curstate->acquired_by)));
}
@@ -1138,7 +1138,7 @@ replorigin_session_setup(RepOriginId node)
if (session_replication_state == NULL && free_slot == -1)
ereport(ERROR,
(errcode(ERRCODE_CONFIGURATION_LIMIT_EXCEEDED),
- errmsg("could not find free replication state slot for replication origin with OID %u",
+ errmsg("could not find free replication state slot for replication origin with ID %u",
node),
errhint("Increase max_replication_slots and try again.")));
else if (session_replication_state == NULL)
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: fix typos
2022-08-01 18:04 fix typos Erik Rijkers <er@xs4all.nl>
2022-08-01 18:11 ` Re: fix typos Justin Pryzby <pryzby@telsasoft.com>
2022-08-04 10:21 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
2022-08-04 13:41 ` Re: fix typos Tom Lane <tgl@sss.pgh.pa.us>
2022-08-05 04:47 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
2022-08-12 06:59 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
2022-08-12 13:55 ` Re: fix typos Tom Lane <tgl@sss.pgh.pa.us>
2022-08-16 01:48 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
@ 2022-08-18 02:11 ` John Naylor <john.naylor@enterprisedb.com>
0 siblings, 0 replies; 27+ messages in thread
From: John Naylor @ 2022-08-18 02:11 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Justin Pryzby <pryzby@telsasoft.com>; Erik Rijkers <er@xs4all.nl>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Tue, Aug 16, 2022 at 8:48 AM John Naylor
<john.naylor@enterprisedb.com> wrote:
>
> On Fri, Aug 12, 2022 at 8:55 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > John Naylor <john.naylor@enterprisedb.com> writes:
> > > This is really a straw-man proposal, since I'm not volunteering to do
> > > the work, or suggest anybody else should do the same. That being the
> > > case, it seems we should just go ahead with Justin's patch for
> > > consistency. Possibly we could also change the messages to say "ID"?
> >
> > I'd be content if we change the user-facing messages (and documentation
> > if any) to say "ID" not "OID".
>
> The documentation has both, so it makes sense to standardize on "ID".
> The messages all had oid/OID, which I changed in the attached. I think
> I got all the places.
>
> I'm thinking it's not wrong enough to confuse people, but consistency
> is good, so backpatch to v15 and no further. Does anyone want to make
> a case otherwise?
This is done.
--
John Naylor
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: fix typos
2022-08-01 18:04 fix typos Erik Rijkers <er@xs4all.nl>
@ 2022-08-02 05:28 ` John Naylor <john.naylor@enterprisedb.com>
2022-08-02 08:32 ` Re: fix typos Erik Rijkers <er@xs4all.nl>
1 sibling, 1 reply; 27+ messages in thread
From: John Naylor @ 2022-08-02 05:28 UTC (permalink / raw)
To: Erik Rijkers <er@xs4all.nl>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Tue, Aug 2, 2022 at 1:05 AM Erik Rijkers <er@xs4all.nl> wrote:
>
> Recent typos...
The part of the sentence inside parentheses is not clear to me, before or
after the patch:
Dropping an extension causes its component objects, and other explicitly
dependent routines (see <xref linkend="sql-alterroutine"/>,
- the depends on extension action), to be dropped as well.
+ that depend on extension action), to be dropped as well.
</para>
--
John Naylor
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: fix typos
2022-08-01 18:04 fix typos Erik Rijkers <er@xs4all.nl>
2022-08-02 05:28 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
@ 2022-08-02 08:32 ` Erik Rijkers <er@xs4all.nl>
2022-08-03 16:41 ` Re: fix typos Robert Haas <robertmhaas@gmail.com>
0 siblings, 1 reply; 27+ messages in thread
From: Erik Rijkers @ 2022-08-02 08:32 UTC (permalink / raw)
To: John Naylor <john.naylor@enterprisedb.com>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; bruce@momjian.us
Op 02-08-2022 om 07:28 schreef John Naylor:
>
> On Tue, Aug 2, 2022 at 1:05 AM Erik Rijkers <er@xs4all.nl
> <mailto:er@xs4all.nl>> wrote:
> >
> > Recent typos...
>
> The part of the sentence inside parentheses is not clear to me, before
> or after the patch:
>
> Dropping an extension causes its component objects, and other
> explicitly
> dependent routines (see <xref linkend="sql-alterroutine"/>,
> - the depends on extension action), to be dropped as well.
> + that depend on extension action), to be dropped as well.
> </para>
>
Hm, I see what you mean, I did not notice that earlier and I won't make
a guess as to intention. Maybe Bruce can have another look? (commit
5fe2d4c56e)
> --
> John Naylor
> EDB: http://www.enterprisedb.com <http://www.enterprisedb.com;
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: fix typos
2022-08-01 18:04 fix typos Erik Rijkers <er@xs4all.nl>
2022-08-02 05:28 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
2022-08-02 08:32 ` Re: fix typos Erik Rijkers <er@xs4all.nl>
@ 2022-08-03 16:41 ` Robert Haas <robertmhaas@gmail.com>
2022-08-04 08:08 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
0 siblings, 1 reply; 27+ messages in thread
From: Robert Haas @ 2022-08-03 16:41 UTC (permalink / raw)
To: Erik Rijkers <er@xs4all.nl>; +Cc: John Naylor <john.naylor@enterprisedb.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Bruce Momjian <bruce@momjian.us>
On Tue, Aug 2, 2022 at 4:32 AM Erik Rijkers <er@xs4all.nl> wrote:
> > The part of the sentence inside parentheses is not clear to me, before
> > or after the patch:
> >
> > Dropping an extension causes its component objects, and other
> > explicitly
> > dependent routines (see <xref linkend="sql-alterroutine"/>,
> > - the depends on extension action), to be dropped as well.
> > + that depend on extension action), to be dropped as well.
> > </para>
> >
>
> Hm, I see what you mean, I did not notice that earlier and I won't make
> a guess as to intention. Maybe Bruce can have another look? (commit
> 5fe2d4c56e)
I think that it's talking about this (documented) syntax:
ALTER ROUTINE name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
[ NO ] DEPENDS ON EXTENSION extension_name
So the change from "depends" to "depend" here is incorrect. Maybe we
can say something like:
the <literal>DEPENDS ON EXTENSION
<replaceable>extension_name</replaceable><literal> action
(I haven't tested whether this markup works.)
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: fix typos
2022-08-01 18:04 fix typos Erik Rijkers <er@xs4all.nl>
2022-08-02 05:28 ` Re: fix typos John Naylor <john.naylor@enterprisedb.com>
2022-08-02 08:32 ` Re: fix typos Erik Rijkers <er@xs4all.nl>
2022-08-03 16:41 ` Re: fix typos Robert Haas <robertmhaas@gmail.com>
@ 2022-08-04 08:08 ` John Naylor <john.naylor@enterprisedb.com>
0 siblings, 0 replies; 27+ messages in thread
From: John Naylor @ 2022-08-04 08:08 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Erik Rijkers <er@xs4all.nl>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>; Bruce Momjian <bruce@momjian.us>
On Wed, Aug 3, 2022 at 11:41 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> I think that it's talking about this (documented) syntax:
>
> ALTER ROUTINE name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ]
> [ NO ] DEPENDS ON EXTENSION extension_name
>
> So the change from "depends" to "depend" here is incorrect. Maybe we
> can say something like:
>
> the <literal>DEPENDS ON EXTENSION
> <replaceable>extension_name</replaceable><literal> action
>
> (I haven't tested whether this markup works.)
Makes sense, I'll go make it happen.
--
John Naylor
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 27+ messages in thread
end of thread, other threads:[~2022-08-18 02:11 UTC | newest]
Thread overview: 27+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2015-05-17 11:46 fix typos Dmitriy Olshevskiy <olshevskiy87@bk.ru>
2015-05-17 12:58 ` Magnus Hagander <magnus@hagander.net>
2019-08-01 12:24 Fix typos Sehrope Sarkuni <sehrope@jackdb.com>
2019-08-02 01:06 ` Re: Fix typos Michael Paquier <michael@paquier.xyz>
2019-08-02 02:18 ` Re: Fix typos Tom Lane <tgl@sss.pgh.pa.us>
2019-08-02 03:01 ` Re: Fix typos Alvaro Herrera <alvherre@2ndquadrant.com>
2019-08-02 04:11 ` Re: Fix typos Michael Paquier <michael@paquier.xyz>
2019-08-02 10:45 ` Re: Fix typos Sehrope Sarkuni <sehrope@jackdb.com>
2019-08-02 10:37 ` Re: Fix typos Sehrope Sarkuni <sehrope@jackdb.com>
2021-04-28 08:23 [PATCH 1/3] Fix typos Kyotaro Horiguchi <horikyota.ntt@gmail.com>
2021-11-29 01:01 Fix typos qianglj.fnst@fujitsu.com <qianglj.fnst@fujitsu.com>
2021-11-30 02:09 ` Re: Fix typos Michael Paquier <michael@paquier.xyz>
2022-08-01 18:04 fix typos Erik Rijkers <er@xs4all.nl>
2022-08-01 18:11 ` Justin Pryzby <pryzby@telsasoft.com>
2022-08-02 05:52 ` John Naylor <john.naylor@enterprisedb.com>
2022-08-04 10:21 ` John Naylor <john.naylor@enterprisedb.com>
2022-08-04 13:41 ` Tom Lane <tgl@sss.pgh.pa.us>
2022-08-05 04:47 ` John Naylor <john.naylor@enterprisedb.com>
2022-08-12 06:59 ` John Naylor <john.naylor@enterprisedb.com>
2022-08-12 12:04 ` Euler Taveira <euler@eulerto.com>
2022-08-12 13:55 ` Tom Lane <tgl@sss.pgh.pa.us>
2022-08-16 01:48 ` John Naylor <john.naylor@enterprisedb.com>
2022-08-18 02:11 ` John Naylor <john.naylor@enterprisedb.com>
2022-08-02 05:28 ` John Naylor <john.naylor@enterprisedb.com>
2022-08-02 08:32 ` Erik Rijkers <er@xs4all.nl>
2022-08-03 16:41 ` Robert Haas <robertmhaas@gmail.com>
2022-08-04 08:08 ` John Naylor <john.naylor@enterprisedb.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox