Update README.md

README.md

@@ -20,15 +20,15 @@ data that applications which monitor the chain need. It provides the following:
 
 ### PostgreSQL table schema changes
 
-This release completely rewrites the SHiP protocol to SQL conversion code so that the database tables
-would directly align with the data structures defined in the SHiP protocol. This also changes the table schema used by previous releases.
+This release completely rewrites the SHiP protocol to SQL conversion code so that the database tables would directly align with the data structures defined in the SHiP protocol. This also changes the table schema used by previous releases.
+
 Here are the basic rules for the conversion:
 
-  - Nested SHiP `struct` types with more than one fields are mapped to SQL custom types.
+  - Nested SHiP `struct` types with more than one field are mapped to SQL custom types.
   - Nested SHiP `vector` types are mapped to SQL arrays.
   - SHiP `variant` types are mapped to a SQL type or table containing the union fields of their constituent types.  
 
-Consequently, instead having their own tables in previous releases, `action_trace`, `action_trace_ram_delta`, `action_trace_auth_sequence` and `action_trace_authorization` are arrays nested inside `transaction_trace` table or `action_trace` type. The SQL `UNNEST` operator can be used to flatten arrays into tables for query. 
+Consequently, instead of having their own tables in previous releases, `action_trace`, `action_trace_ram_delta`, `action_trace_auth_sequence` and `action_trace_authorization` are arrays nested inside `transaction_trace` table or `action_trace` type. The SQL `UNNEST` operator can be used to flatten arrays into tables for query. 
 
 The current list of tables created by  `fill-pg` are:
   - account
@@ -60,8 +60,7 @@ The current list of tables created by  `fill-pg` are:
 
 This release upgrades `fill-pg` to support `nodeos` v2.1.0. The remaining tools are still disabled and have not been upgraded. The schema used by
 `fill-pg` has changed. At present no data migration tool is available, so data may be manually migrated, regenerated by replaying
-from the desired block number, or exist side by side in two schemas, with older blocks in the v0.3.0 schema and newer blocks in
-the new schema.  Use of the `--pg-schema` option will facilitate the transition. 
+from the desired block number, or exist side by side in two schemas, with older blocks in the v0.3.0 schema and newer blocks in the new schema.  Use of the `--pg-schema` option will facilitate the transition. 
 
 Full details of the differences can be found via diff of plain text backups of each schema using `pg_dump`, not included here
 for brevity.