Spelling

docs/design.md

@@ -22,7 +22,7 @@ The Postgres extension installer (pgext) tool helps user build and install exten
 To install an extension, the installer will read the extension download URL from the plugindb config file, which
 decides how to install the extension (i.e., by calling `CREATE EXTENSION` or add to `shared_preload_library`). The installer automatically detects the PGXS Makefile in the extension source code, compiles it, and installs it to our Postgres instance.
 
-To collect information in the system, the installer will install our homemade extensions: `pgx_show_hooks` and `pgx_trace_hooks`. `pgx_show_hooks` adds a return set function to the system to collect the value of the function pointers of the hooks, so as to determine which hooks are used by the currently-installed extensions. `pgx_trace_hooks` will log all information when a hook is called, so that the installer can analyze the information to determine compability.
+To collect information in the system, the installer will install our homemade extensions: `pgx_show_hooks` and `pgx_trace_hooks`. `pgx_show_hooks` adds a return set function to the system to collect the value of the function pointers of the hooks, so as to determine which hooks are used by the currently-installed extensions. `pgx_trace_hooks` will log all information when a hook is called, so that the installer can analyze the information to determine compatibility.
 
 ### Extension Framework
 
@@ -71,10 +71,10 @@ During our initial study on Postgres extensions, we identified and categorized e
 This is the case where an extension cannot be successfully installed to Postgres due to some internal/external dependencies. One example of installation conflict is that some extensions include Postgres source code, and therefore its correctness relies on whether it is being compiled and installed to the same Postgres version. The installer can take care of it.
 
 #### Erroneous Results
-This is the case where two extensions can be installed together but doing so results in crashing the program or producing erroneous results because they are using a same hook. To detect incompatibility associated with erroneous results, we can generate SQLs that covers code path of the extension based on the existing test cases for the extension. If extensions behave differently in different environments with the same set of SQL queires, then they cannot exist at the same time. This type of conflict is possible to be automatically detected by extending tools like [SQLSmith](https://github.com/anse1/sqlsmith) and [Squrriel](https://github.com/s3team/Squirrel).
+This is the case where two extensions can be installed together but doing so results in crashing the program or producing erroneous results because they are using a same hook. To detect incompatibility associated with erroneous results, we can generate SQLs that covers code path of the extension based on the existing test cases for the extension. If extensions behave differently in different environments with the same set of SQL queries, then they cannot exist at the same time. This type of conflict is possible to be automatically detected by extending tools like [SQLSmith](https://github.com/anse1/sqlsmith) and [Squirrel](https://github.com/s3team/Squirrel).
 
-#### Unintented Behavior
-This is the case where two extensions are technically compatible with each other but doing so results in having unexpected results because they are using a same hook. For example, pg_hint_plan includes some parts of pg_stat_statements source code to ensure the plan hints (part of the SQL comments) are properly stored in the statistics table. To detect incompatibility associated with unintented behavior, we can first apply the same strategy as for erroneous results, but then we will have to manually review all extensions to determine which category they belong.
+#### Unintended Behavior
+This is the case where two extensions are technically compatible with each other but doing so results in having unexpected results because they are using a same hook. For example, pg_hint_plan includes some parts of pg_stat_statements source code to ensure the plan hints (part of the SQL comments) are properly stored in the statistics table. To detect incompatibility associated with unintended behavior, we can first apply the same strategy as for erroneous results, but then we will have to manually review all extensions to determine which category they belong.
 
 
 ## Testing Plan

pgext-cli/src/cmd_init.rs

@@ -5,7 +5,7 @@ use anyhow::Result;
 use crate::config::WorkspaceConfig;
 use crate::CmdInit;
 
-/// Initialze the workspace
+/// Initialize the workspace
 pub fn cmd_init(cmd: CmdInit) -> Result<()> {
   println!("pg_config: {}", cmd.pg_config);
   println!("pg_data: {}", cmd.pg_data);

pgext-cli/src/download.rs

@@ -34,7 +34,7 @@ pub fn download_zip(zip_url: String, download_path: &Path, build_dir: &Path, ver
   Ok(())
 }
 
-/// Download an uncompress a tar file
+/// Download and uncompress a tar file
 pub fn download_tar(tar_url: String, download_path: &Path, build_dir: &Path, verbose: bool) -> Result<()> {
   if download_path.exists() {
     println!("{} {}", style("Skipping Download").bold().blue(), tar_url);

pgext-cli/src/test_control.rs

@@ -7,7 +7,7 @@ use crate::plugin::{InstallStrategy, Plugin};
 
 /// An extension test controller trait
 pub trait ExtTestControl {
-  /// Connect to an postgres database for testing
+  /// Connect to a postgres database for testing
   fn connect_test_db() -> Result<Client>;
   /// Handle extensions already installed in the database before testing
   fn handle_installed<F: Fn(String)>(&mut self, println: F) -> Result<()>;