s/etc./*etc.*/g

1 files changed, 6 insertions, 6 deletions

diff --git a/_articles/2020-08-31-the-database-i-wish-i-had.md b/_articles/2020-08-31-the-database-i-wish-i-had.md
index 004a558..a134e2c 100644
--- a/_articles/2020-08-31-the-database-i-wish-i-had.md
+++ b/_articles/2020-08-31-the-database-i-wish-i-had.md
@@ -48,7 +48,7 @@ Let's go over what I mean by each of those aspects one by one.
 I think the server-side database landscape is diverse and mature enough for
 my needs (even though I end up choosing SQLite most of the time), and what I'm
 after is a database to be embedded on client-side applications itself, be it
-desktop, browser, mobile, etc.
+desktop, browser, mobile, *etc.*
 
 The purpose of such database is not to keep some local cache of data in case of
 lost connectivity: we have good solutions for that already. It should serve as
@@ -84,13 +84,13 @@ that would have to be emulated~~[^posix-sqlite].
     page. SQLite still is an implementation of a update-in-place, SQL,
     table-oriented database. It is probably true that cherry-picking the
     relevant parts of SQLite (like storage access, consistency, crash recovery,
-    parser generator, etc.) and leaving out the unwanted parts (SQL, tables,
-    threading, etc.) would be better than including the full SQLite stack, but
+    parser generator, *etc.*) and leaving out the unwanted parts (SQL, tables,
+    threading, *etc.*) would be better than including the full SQLite stack, but
     that's simply an optimization. Both could even coexist, if desired.
 
     SQLite would have to be treated similarly to how Datomic treats SQL
     databases: instead of having a table for each entities, spread attributes
-    over the tables, etc., it treats SQL databases as a key-value storage so it
+    over the tables, *etc.*, it treats SQL databases as a key-value storage so it
     doesn't have to re-implement interacting with the disk that other databases
     do well.
 
@@ -107,7 +107,7 @@ Node.js. However I want a tool that can be deployed anywhere, and not limit its
 applications to places that already have a JavaScript runtime environment, or
 force the developer to bundle a JavaScript runtime environment with their
 application. This is true for GTK+ applications, command line programs, Android
-apps, etc.
+apps, *etc.*
 
 [pouchdb]: https://pouchdb.com/
 [couchdb]: https://couchdb.apache.org/
@@ -133,7 +133,7 @@ This would allow the database to adapt to where it is embedded: when targeting
 the browser the IndexedDB storage API would provide the persistence layer
 that the database requires, and similarly the POSIX filesystem storage API would
 provide the persistence layer when targeting POSIX systems (like desktops,
-mobile, etc.).
+mobile, *etc.*).
 
 But there's also an extra restriction that comes from by being embedded: it
 needs to provide and embeddable artifact, most likely a binary library object