Fix typos

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/gotchas_and_syntax.md

@@ -135,7 +135,7 @@ This section outlines behaviors and limitations in `pg_duckdb`, things to know t
 
 ### Querying
 
-- **Standard SQL is the default**. For analytical queries on your PostgreSQL tables, use standard SQL. `pg_duckdb` accelerates them automatically as long as you configure `duckdb.force_excecution=true`. No special functions are needed.
+- **Standard SQL is the default**. For analytical queries on your PostgreSQL tables, use standard SQL. `pg_duckdb` accelerates them automatically as long as you configure `duckdb.force_execution=true`. No special functions are needed.
 
 - **Use `r['column']` for external files**. When using `read_parquet()`, `read_csv()`, etc., you must access columns with the `r['column_name']` syntax, where `r` is the alias for the function call.
 

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

@@ -8,7 +8,7 @@ Able to read many [data types](https://www.postgresql.org/docs/current/datatype.
 - `text`/`varchar`/`bpchar`
 - `bit` related types, including both fixed and varied sized bit array
 - `bytea`/`blob`
-- `timestamp`/`timstampz`/`date`/`interval`/`timestamp_ns`/`timestamp_ms`/`timestamp_s`
+- `timestamp`/`timestampz`/`date`/`interval`/`timestamp_ns`/`timestamp_ms`/`timestamp_s`
 - `boolean`
 - `uuid`
 - `json`/`jsonb`
@@ -29,7 +29,7 @@ The type support in `pg_duckdb` is not yet complete (and might never be). The
 following are known issues that you might run into. Feel free to contribute PRs
 to fix these limitations:
 
-1. `enum` types are not supported (PR is progress)
+1. `enum` types are not supported (PR in progress)
 2. The DuckDB `decimal` type doesn't support the wide range of values that the Postgres `numeric` type does. To avoid errors when converting between the two, `numeric` is converted to `double precision` internally if `DuckDB` does not support the required precision. Obviously this might cause precision loss of the values.
 3. The DuckDB `timestamp_ns` type gets truncated to microseconds when it is converted to the Postgres `timestamp` type, which loses precision in the output. Operations on a `timestamp_ns` value, such as sorting/grouping/comparing, will use the full precision.
 4. `jsonb` columns are converted to `json` columns when reading from DuckDB. This is because DuckDB does not have a `jsonb` type.
@@ -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
@@ -28,7 +28,7 @@ Then clone this repository and install the dependencies:
 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

src/pgduckdb_hooks.cpp

@@ -451,7 +451,7 @@ DuckdbEmitLogHook(ErrorData *edata) {
 		if (ContainsDuckdbRowReturningFunction(debug_query_string)) {
 			edata->hint = pstrdup("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.");
+			                      "you're already doing that, maybe you forgot to give the function the r alias.");
 		}
 	} else if (edata->elevel == ERROR && edata->sqlerrcode == ERRCODE_SYNTAX_ERROR &&
 	           pgduckdb::IsExtensionRegistered() &&

test/regression/expected/array_problems.out

@@ -42,7 +42,7 @@ TRUNCATE s;
 INSERT INTO s VALUES(ARRAY[['a', 'b'],['c','d']]);
 SELECT * FROM s;
 ERROR:  (PGDuckDB/Duckdb_ExecCustomScan_Cpp) Invalid Input Error: Dimensionality of the schema and the data does not match, data contains more dimensions than the amount of dimensions specified by the schema
--- But if you change the defintion of the table, we will be able to handle it.
+-- But if you change the definition of the table, we will be able to handle it.
 ALTER TABLE s ALTER COLUMN a SET DATA TYPE text[][];
 SELECT * FROM s;
        a       

test/regression/expected/read_functions.out

@@ -89,7 +89,7 @@ SELECT * FROM (
 (1 row)
 
 -- NOTE: A single "r" is equivalent to a *. The prefix and postfix columns are
--- not explicitely selected, but still show up in the result. This is
+-- not explicitly selected, but still show up in the result. This is
 -- considered a bug, but it's one that we cannot easily solve because the "r"
 -- reference does not exist in the DuckDB query at all, so there's no way to
 -- reference only the columns coming from that part of the subquery. Very few
@@ -320,7 +320,7 @@ SELECT count("sepal.length") FROM read_parquet('../../data/iris.parquet');
 ERROR:  column "sepal.length" does not exist
 LINE 1: SELECT count("sepal.length") FROM read_parquet('../../data/i...
                      ^
-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.
 -- But again only show it when we use functions that return duckdb.rows
 SELECT count("sepal.length") FROM generate_series(1, 100) a(x);
 ERROR:  column "sepal.length" does not exist

test/regression/expected/transactions.out

@@ -52,7 +52,7 @@ INSERT INTO t VALUES (2);
 INSERT INTO t_ddb VALUES (2);
 ERROR:  (PGDuckDB/DuckdbExecutorStartHook_Cpp) Not implemented Error: Writing to DuckDB and Postgres tables in the same transaction block is not supported
 ROLLBACK;
--- Unless users explicitely opt-in
+-- Unless users explicitly opt-in
 BEGIN;
 SET LOCAL duckdb.unsafe_allow_mixed_transactions = true;
 INSERT INTO t_ddb VALUES (4);
@@ -328,7 +328,7 @@ NOTICE:  table "t_doesnotexist" does not exist, skipping
 END;
 CREATE TEMP TABLE t_ddb(a int) USING duckdb;
 -- It should also not be allowed to drop duckdb and postgres tables in the same
--- transaction if it's implicitely done using a DROP SCHEMA ... CASCADE.
+-- transaction if it's implicitly done using a DROP SCHEMA ... CASCADE.
 CREATE SCHEMA mixed;
 CREATE TEMP TABLE t_ddb2(a int) USING duckdb;
 -- Insert a row into pg_depend to make t_ddb depend on the mixed schema. We do

test/regression/sql/array_problems.sql

@@ -22,7 +22,7 @@ TRUNCATE s;
 -- error.
 INSERT INTO s VALUES(ARRAY[['a', 'b'],['c','d']]);
 SELECT * FROM s;
--- But if you change the defintion of the table, we will be able to handle it.
+-- But if you change the definition of the table, we will be able to handle it.
 ALTER TABLE s ALTER COLUMN a SET DATA TYPE text[][];
 SELECT * FROM s;
 

test/regression/sql/read_functions.sql

@@ -40,7 +40,7 @@ SELECT * FROM (
 ) q;
 
 -- NOTE: A single "r" is equivalent to a *. The prefix and postfix columns are
--- not explicitely selected, but still show up in the result. This is
+-- not explicitly selected, but still show up in the result. This is
 -- considered a bug, but it's one that we cannot easily solve because the "r"
 -- reference does not exist in the DuckDB query at all, so there's no way to
 -- reference only the columns coming from that part of the subquery. Very few

test/regression/sql/transactions.sql

@@ -36,7 +36,7 @@ INSERT INTO t VALUES (2);
 INSERT INTO t_ddb VALUES (2);
 ROLLBACK;
 
--- Unless users explicitely opt-in
+-- Unless users explicitly opt-in
 BEGIN;
 SET LOCAL duckdb.unsafe_allow_mixed_transactions = true;
 INSERT INTO t_ddb VALUES (4);
@@ -276,7 +276,7 @@ CREATE TEMP TABLE t_ddb(a int) USING duckdb;
 
 
 -- It should also not be allowed to drop duckdb and postgres tables in the same
--- transaction if it's implicitely done using a DROP SCHEMA ... CASCADE.
+-- transaction if it's implicitly done using a DROP SCHEMA ... CASCADE.
 CREATE SCHEMA mixed;
 CREATE TEMP TABLE t_ddb2(a int) USING duckdb;
 -- Insert a row into pg_depend to make t_ddb depend on the mixed schema. We do