Fix typos
Hi,
Attached fixes some typos for "serialise" => "serialize" and "materialise"
=> "materialize".
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
Attachments:
0001-Fix-typos.patchtext/x-patch; charset=US-ASCII; name=0001-Fix-typos.patchDownload
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
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
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:
/messages/by-id/CA+hUKGJz-pdMgWXroiwvN-aeG4-AjdWj3gWdQKOSa8g65spdVw@mail.gmail.com
regards, tom lane
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:/messages/by-id/CA+hUKGJz-pdMgWXroiwvN-aeG4-AjdWj3gWdQKOSa8g65spdVw@mail.gmail.com
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
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
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:/messages/by-id/CA+hUKGJz-pdMgWXroiwvN-aeG4-AjdWj3gWdQKOSa8g65spdVw@mail.gmail.com
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:
v2-0001-Use-American-spelling-for-serialize-and-materalize.patchapplication/x-patch; name=v2-0001-Use-American-spelling-for-serialize-and-materalize.patchDownload
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
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/