Fix typos

CHANGES

@@ -10,14 +10,14 @@ In 4.6.0
 * Fix `-if(?OTP_RELEASE ...)` (was missing question mark) #255
 * Do not format certain attributes of `State` on abnormal epgsql
   sock termination (common reason for OOM) #257
-* Make dialyzer warn about use of unknown types; fix some occurences of such #259
+* Make dialyzer warn about use of unknown types; fix some occurrences of such #259
 * Migrate from travis-ci to github actions; test on PostgreSQL 12 #262, #264
 * Introduce transaction_opts type #261
 
 In 4.5.0
 
 * Add support for `application_name` connection parameter #226
-* Execute request cancelation over TLS, when main connection is TLS as well #227
+* Execute request cancellation over TLS, when main connection is TLS as well #227
 * Handle skipped commands in execute_batch #228
 * Add sasl_prep implementation for validating passwords according to sasl specification #229
 * OTP-23 in CI #237
@@ -90,7 +90,7 @@ In 4.2.0
 * Passwords are obfuscated before they sent to connection process. This is to avoid plain
   DB passwords to be dumped to SASL crash log
 * Password can be provided as a fun: `fun ( () -> iodata() )`
-* `platform_define` macroses were simplified. It's now possible to build epgsql even without
+* `platform_define` macros were simplified. It's now possible to build epgsql even without
   rebar on all supported OTP versions
 
 In 4.1.0
@@ -149,7 +149,7 @@ Incompatibilities:
   modifications were made to this code.
 * Passing integer / atom / float as a value of a text / varchar / bytea query parameter is now
   deprecated (so, `epgsql:equery(C, "SELECT $1::text", [my_atom])` will still work but is not recommended)
-* Redshift and CockroachDB users might expirience some problems. Please, report bugs!
+* Redshift and CockroachDB users might experience some problems. Please, report bugs!
 
 In 3.4.0
 

README.md

@@ -571,7 +571,7 @@ see `epgsql.hrl` for the record definition. `epgsql` functions may also return
 - `{unsupported_auth_method, Method}`     - required auth method is unsupported
 - `timeout`                               - request timed out
 - `closed`                                - connection was closed
-- `sync_required`                         - error occured and epgsql:sync must be called
+- `sync_required`                         - error occurred and epgsql:sync must be called
 
 ## Server Notifications
 
@@ -651,7 +651,7 @@ Options (proplist or map):
 
 `epgsql{a,i}:get_cmd_status(C) -> undefined | atom() | {atom(), integer()}`
 
-This function returns the last executed command's status information. It's usualy
+This function returns the last executed command's status information. It's usually
 the name of SQL command and, for some of them (like UPDATE or INSERT) the
 number of affected rows. See [libpq PQcmdStatus](https://www.postgresql.org/docs/current/static/libpq-exec.html#LIBPQ-PQCMDSTATUS).
 But there is one interesting case: if you execute `COMMIT` on a failed transaction,

doc/overview.edoc

@@ -36,7 +36,7 @@ This mapping is handled by {@link epgsql_oid_db} module and is populated at
 connection set-up time by {@link epgsql_cmd_connect}.
 
 Most of the connection initialization (network connection, authentication, codecs)
-is performed by {@link epgsql_cmd_connect} command, wich is just a regualr command
+is performed by {@link epgsql_cmd_connect} command, which is just a regular command
 (but quite complex one) and can be replaced by own implementation if needed.
 
 == Commands ==

doc/pluggable_commands.md

@@ -95,17 +95,17 @@ will be `query_error()` instead of binary.
 
 This callback should return one of the following responses to control command's behaviour:
 
-- `{noaction, pg_sock()}` - to do nothing (this usualy means that packet was ignored)
+- `{noaction, pg_sock()}` - to do nothing (this usually means that packet was ignored)
 - `{noaction, pg_sock(), state()}` - do nothing, but update command's state
 - `{add_row, tuple(), pg_sock(), state()}` - add a row to current resultset rows accumulator.
   You may get the current accumulated resultset by `epgsql_sock::get_rows(pg_sock())` (except
   when `epgsqli` interface is used).
 - `{add_result, Result :: any(), Notification :: any(), pg_sock(), state()}` - add a
-  new result to the list of results. Usualy all commands have only a single result, except `squery`, when
+  new result to the list of results. Usually all commands have only a single result, except `squery`, when
   multiple SQL queries were passed, separated by a semicolon and `execute_batch`.
   You will usually will just return something like `{ok, epgsql_sock:get_rows(PgSock)}` or an error as a result. `Notification` is used for `epgsqli` interface.
   You may get the current list of accumulated results with `epgsql_sock:get_results(pg_sock())`.
-- `{finish, Results, Notification, pg_sock(), state()}` - returned when command was successfuly
+- `{finish, Results, Notification, pg_sock(), state()}` - returned when command was successfully
   executed and no more actions needed. `Results` will be returned to a client as a result of command
   execution and the command will be descheduled from epgsql connection process.
   You usually use the result of `epgsql_sock:get_results/1` as a `Results`.
@@ -114,17 +114,17 @@ This callback should return one of the following responses to control command's
   once again (with a new state). This means that the `execute/2` callback will be executed again and
   new packets may be sent from client to server. This way you can implement chatty commands with
   multiple `request -> response` sequences. See `epgsql_cmd_connect` as an example.
-- `{stop, Reason, Response, pg_sock()}` - returned when some unrecoverable error occured and
+- `{stop, Reason, Response, pg_sock()}` - returned when some unrecoverable error occurred and
   you want to terminate epgsql connection process. `Response` will be returned as a command result
   and `Reason` will be process termination reason.
   Please, try to avoid use of this response if possible.
 - `{sync_required, Why}` - returned to finish command execution, flush enqueued but not yet
   executed commands and to set epgsql process to `sync_required` state. In this state it
   will not accept any commands except `epgsql_cmd_sync`.
-  This usualy means that multipacket protocol sequence was done out-of-order (eg, `bind` before `parse`),
+  This usually means that multipacket protocol sequence was done out-of-order (eg, `bind` before `parse`),
   so, client and server states are out-of-sync and we need to reset them.
 - `unknown` - command got unexpected packet. Connection process will be terminated with
-  `{error, {unexpected_message, Type, Payload, state()}}`. Usualy returned from a
+  `{error, {unexpected_message, Type, Payload, state()}}`. Usually returned from a
   catch-all last clause.
 
 ### Command now can be executed

doc/pluggable_types.md

@@ -3,7 +3,7 @@
 It's possible to make a custom datatype encoder/decoder as well as to change encoding/decoding
 of existing supported datatype.
 You can't have specific decoding rules for specific column or for specific query. Codec update
-affects any occurence of this datatype for this connection.
+affects any occurrence of this datatype for this connection.
 
 ## Possible usecases
 
@@ -43,9 +43,9 @@ encode(Data :: any(), epgsql:type_name(), codec_state()) -> iodata().
 Will be called when parameter of matching type is passed to `equery` or `bind` etc.
 2nd argument is the name of matching type (useful when `names/0` returns more than one name).
 It should convert data to iolist / binary in a postgresql binary format representation.
-Postgresql binary format usualy not documented, so you most likely end up checking postgresql
+Postgresql binary format usually not documented, so you most likely end up checking postgresql
 [source code](https://github.com/postgres/postgres/tree/master/src/backend/utils/adt).
-*TIP*: it's usualy more efficient to encode data as iolist, because in that case it will be
+*TIP*: it's usually more efficient to encode data as iolist, because in that case it will be
 written directly to socket without any extra copying. So, you don't need to call
 `iolist_to_binary/1` on your data before returning it from this function.
 

src/datatypes/epgsql_codec_postgis.erl

@@ -1,7 +1,7 @@
 %%% @doc
 %%% Codec for `geometry' PostGIS umbrella datatype.
 %%%
-%%% XXX: PostGIS is not a Postgres's built-in datatype! It should be instaled
+%%% XXX: PostGIS is not a Postgres's built-in datatype! It should be installed
 %%% separately and enabled via `CREATE EXTENSION postgis'.
 %%% <ul>
 %%%  <li>[http://postgis.net/docs/manual-2.4/geometry.html]</li>

src/datatypes/epgsql_codec_text.erl

@@ -5,7 +5,7 @@
 %%% contains not just `byte()', an attempt to perform unicode conversion will be made.
 %%%
 %%% Also, `integer()', `float()' and `atom()' are automatically converted to
-%%% strings, but this kind of conversion might be eventualy removed.
+%%% strings, but this kind of conversion might be eventually removed.
 %%% <ul>
 %%%  <li>[https://www.postgresql.org/docs/10/static/datatype-character.html]</li>
 %%%  <li>$PG$/src/backend/utils/adt/varchar.c</li>

src/epgsql.erl

@@ -422,7 +422,7 @@ with_transaction(C, F) ->
 %%   `{rollback, ErrorReason}' will be returned. Default: `true'</dd>
 %%  <dt>ensure_comitted</dt>
 %%  <dd>even when callback returns without exception,
-%%   check that transaction was comitted by checking CommandComplete status
+%%   check that transaction was committed by checking CommandComplete status
 %%   of "COMMIT" command. In case when transaction was rolled back, status will be
 %%   "rollback" instead of "commit". Default: `false'</dd>
 %%  <dt>begin_opts</dt>

test/epgsql_SUITE.erl

@@ -32,7 +32,7 @@ all() ->
 
 groups() ->
     SubGroups = [
-        {connect, [parrallel], [
+        {connect, [parallel], [
             connect,
             connect_with_application_name,
             connect_to_db,