Fix typos (#968)

Same as #962 but with merge conflicts resolved

Co-authored-by: Cheng Chen <[email protected]>

Author: JelteF

CHANGELOG.md

@@ -29,7 +29,7 @@
 - Update to DuckDB 1.3.2. ([#754], [#858])
 - Change the way MotherDuck is configured. It's not done anymore through the Postgres configuration file. Instead, you should now enable MotherDuck using `CALL duckdb.enable_motherduck(...)` or equivalent `CREATE SERVER` and `CREATE USER MAPPING` commands. ([#668])
 - Change the way secrets are added to DuckDB. You'll need to recreate your secrets using the new method `duckdb.create_simple_secret` or `duckdb.create_azure_secret` functions. Internally secrets are now stored `SERVER` and `USER MAPPING` for the `duckdb` foreign data wrapper. ([#697])
-- Disallow DuckDB execution inside functions by default. This feature can cause crashes in rare cases and is intended to be re-enabled in a future release. For now you can use `duckdb.unsafe_allow_execution_inside_function` to allow functions anyway. ([#764], [#884])
+- Disallow DuckDB execution inside functions by default. This feature can cause crashes in rare cases and is intended to be re-enabled in a future release. For now you can use `duckdb.unsafe_allow_execution_inside_functions` to allow functions anyway. ([#764], [#884])
 - Don't convert Postgres NUMERICs with a precision that's unsupported in DuckDB to double by default. Instead it will throw an error. If you want the lossy conversion to DOUBLE to happen, you can enable `duckdb.convert_unsupported_numeric_to_double`. ([#795])
 - Remove custom HTTP caching logic. ([#644])
 - When creating a table in a `ddb$` schema that table now uses the `duckdb` table access method by default. ([#650])

docs/settings.md

@@ -57,7 +57,7 @@ Determines whether community extensions can be installed.
 - **Default**: `false`
 - **Access**: Superuser-only
 
-### `duckdb.unsafe_allow_execution_inside_function`
+### `duckdb.unsafe_allow_execution_inside_functions`
 
 Allows DuckDB execution inside PostgreSQL functions. This feature can cause crashes in rare cases and is disabled by default. Use with caution.
 

docs/types.md

@@ -121,7 +121,7 @@ SELECT * FROM mycte WHERE company = 'DuckDB Labs';
 -- ERROR:  42703: column "company" does not exist
 -- LINE 5: SELECT * FROM mycte WHERE company = 'DuckDB Labs';
 --                                   ^
--- HINT:  If you use DuckDB functions like read_parquet, you need to use the r['colname'] syntax to use columns. If you're already doing that, maybe you forgot to to give the function the r alias.
+-- HINT:  If you use DuckDB functions like read_parquet, you need to use the r['colname'] syntax to use columns. If you're already doing that, maybe you forgot to give the function the r alias.
 ```
 
 This is easy to work around by using the `r['colname']` syntax like so:

include/pgduckdb/utility/cpp_wrapper.hpp

@@ -53,7 +53,7 @@ __CPPFunctionGuard__(const char *func_name, const char *file_name, int line, Fun
 	// }
 
 	// In this case the `PG_CATCH` block that will handle the error thrown below
-	// would try to reset the stack to the begining of `my_func` and crash
+	// would try to reset the stack to the beginning of `my_func` and crash
 	//
 	// So instead this should also be wrapped in a `InvokeCPPFunc` like:
 	//

include/pgduckdb/vendor/pg_numeric_c.hpp

@@ -19,7 +19,7 @@
  *-------------------------------------------------------------------------
  */
 
-// Removed all un-neccessary includes
+// Removed all un-necessary includes
 #include "postgres.h"
 #include "utils/numeric.h"
 #include "lib/hyperloglog.h"

scripts/tpch/README.md

@@ -7,7 +7,7 @@ easiest way to do this is using docker:
 # Simply run this to enable motherduck:
 docker run --rm -e POSTGRES_HOST_AUTH_METHOD=trust --network=host -d --name pgduck -e MOTHERDUCK_TOKEN \
     pgduckdb/pgduckdb:18-main
-# For real benchmarks it's recommended to configure Postgres its its settings,
+# For real benchmarks it's recommended to configure Postgres its settings,
 # as well as docker its --shm-size to be a good match for your machine. For the
 # best results this obviously requires tuning.
 # A decent starting point for an AWS c6a.8xlarge (32 vCPU, 64GB RAM) instance
@@ -35,7 +35,7 @@ curl -LsSf https://astral.sh/uv/install.sh | sh
 After that you can use `./run.py` (see `run.py --help` for details) to run a
 TCPH-like benchmark. Check `./run.py --help` for details on the arguments. A
 simple example that compares the DuckDB engine and the Postgres engine on an
-extremely tiny dataset dataset (for real performance comparisons real use scale
+extremely tiny dataset (for real performance comparisons real use scale
 factors of 1 or higher):
 
 ```bash

sql/pg_duckdb--1.0.0.sql

@@ -1,6 +1,6 @@
 LOAD 'pg_duckdb';
 
--- We create a duckdb schema to store most of our things. We explicitely
+-- We create a duckdb schema to store most of our things. We explicitly
 -- don't use CREATE IF EXISTS or the schema key in the control file, so we know
 -- for sure that the extension will own the schema and thus non superusers
 -- cannot put random things in it, so we can assume it's safe. A few functions

src/pg/pgduckdb_subscript.cpp

@@ -52,13 +52,13 @@ CoerceSubscriptToText(struct ParseState *pstate, A_Indices *subscript, const cha
 }
 
 /*
- * In Postgres all index operations in a row ar all slices or all plain
+ * In Postgres all index operations in a row are all slices or all plain
  * index operations. If you mix them, all are converted to slices.
  * There's no difference in representation possible between
- * "col[1:2][1]" and "col[1:2][1:]". If you want this seperation you
- * need to use parenthesis to seperate: "(col[1:2])[1]"
+ * "col[1:2][1]" and "col[1:2][1:]". If you want this separation you
+ * need to use parenthesis to separate: "(col[1:2])[1]"
  * This might seem like fairly strange behaviour, but Postgres uses
- * this to be able to slice in multi-dimensional arrays and thtis
+ * this to be able to slice in multi-dimensional arrays and this
  * behaviour is documented here:
  * https://www.postgresql.org/docs/current/arrays.html#ARRAYS-ACCESSING
  *

src/pgduckdb_background_worker.cpp

@@ -984,7 +984,7 @@ DropRelation(const char *fully_qualified_table, char relation_kind, bool drop_wi
 		return false;
 	}
 	/*
-	 * We explicitely don't call SPI_commit_that_works_in_background_worker
+	 * We explicitly don't call SPI_commit_that_works_in_background_worker
 	 * here, because that makes transactional considerations easier. And when
 	 * deleting tables, it doesn't matter how long we keep locks on them,
 	 * because they are already deleted upstream so there can be no queries on

src/pgduckdb_ddl.cpp

@@ -1117,8 +1117,8 @@ DuckdbShouldCallDDLHooks(PlannedStmt *pstmt) {
 	 */
 	if (IsA(parsetree, TransactionStmt)) {
 		/*
-		 * We could explicitely only check for BEGIN, but any others won't be
-		 * the first query in a session anyway (so initialzing caching doesn't
+		 * We could explicitly only check for BEGIN, but any others won't be
+		 * the first query in a session anyway (so initializing caching doesn't
 		 * matter).
 		 *
 		 * Secondly, we also don't want to do anything for transaction
@@ -1455,7 +1455,7 @@ DECLARE_PG_FUNCTION(duckdb_drop_trigger) {
 	 * 1. Each table owns two types:
 	 *	 a. the composite type matching its columns
 	 *	 b. the array of that composite type
-	 * 2. There can also be many implicitely connected things to a table, like sequences/constraints/etc
+	 * 2. There can also be many implicitly connected things to a table, like sequences/constraints/etc
 	 *
 	 * So here we try to count all the objects that are not connected to a
 	 * table. Sadly at this stage the objects are already deleted, so there's