look at all that

Author: levkk

docs/features/sharding/manual-routing.md

@@ -30,7 +30,7 @@ The PostgreSQL query language supports adding inline comments to queries. They a
     The following query will be sent to shard number zero:
 
     ```postgresql
-    /* pgdog_shard: 0 */ CREATE INDEX CONCURRENTLY users_id_idx USING btree(id);
+    /* pgdog_shard: 0 */ CREATE INDEX CONCURRENTLY users_id_idx ON users USING btree(id);
     ```
 === "Sharding key"
     This query will be sent to whichever shard maps to the key `"us-east-1"`:
@@ -70,7 +70,7 @@ The `SET` command comes from the PostgreSQL query language and is used to change
     ```postgresql
     BEGIN;
     SET LOCAL pgdog.shard TO 0;
-    CREATE INDEX users_id_idx USING btree(id);
+    CREATE INDEX users_id_idx ON users USING btree(id);
     COMMIT;
     ```
 === "Sharding key"

docs/features/sharding/sequences.md

@@ -27,14 +27,16 @@ Sharded sequences combine two Postgres primitives:
 The two are called inside a PL/pgSQL function that fetches numbers from a sequence until `satisfies_hash_partition` returns `true`, for the total number of shards in the cluster and the shard number it's being executed on:
 
 ```postgresql
-LOOP
-  SELECT nextval('normal_seq'::regclass) INTO val;
+DO $$
+BEGIN
+  LOOP
+    SELECT nextval('normal_seq'::regclass) INTO val;
 
-  IF satisfies_hash_partition(/* ... */, val) THEN
+    IF satisfies_hash_partition(/* ... */, val) THEN
       RETURN val;
-  END IF;
-
-END;
+    END IF;
+  END LOOP;
+END $$;
 ```
 
 Since fetching values from a sequence is very quick, we are able to find the correct number without introducing significant latency to row creation. The Postgres hash function is also good at producing uniform outputs, so all shards will have similar, small gaps between generated numbers.

docs/features/sharding/sharding-functions.md

@@ -51,18 +51,27 @@ All queries referencing the `user_id` column will be automatically sent to the m
         Different integer types are treated the same by the query router. If you're using `BIGINT`, `INTEGER` or `SMALLINT` as your sharding key, you can specify `bigint` in the configuration:
 
     ```toml
+    [[sharded_tables]]
+    database = "prod"
+    column = "user_id"
     data_type = "bigint"
     ```
 === "Text"
     !!! note "Text types"
         `VARCHAR`, `VARCHAR(n)`, and `TEXT` use the same encoding and are treated the same by the query router. For either one, you can specify `varchar` in the configuration:
     ```toml
+    [[sharded_tables]]
+    database = "prod"
+    column = "serial_number"
     data_type = "varchar"
     ```
 === "UUID"
     !!! note "UUID types"
         Only UUIDv4 is currently supported for sharding in the query router.
     ```toml
+    [[sharded_tables]]
+    database = "prod"
+    column = "unique_id"
     data_type = "uuid"
     ```
 

docs/migrating-to-pgdog/from-pgbouncer.md

@@ -58,8 +58,8 @@ Both PgBouncer and PgDog can override the user's password used to connect to Pos
     name = "prod"
     host = "10.0.0.1"
     port = 5432
-    server_user = "postgres"
-    server_password = "hunter2"
+    user = "postgres"
+    password = "hunter2"
     pooler_mode = "transaction"
     ```
 

tests/test_code_blocks.py

@@ -30,6 +30,7 @@ def verify(binary):
             info = m.group("info").strip().lower()
             indent = m.group("indent")
             code = m.group("code")
+            original = code
             if indent:
                 # Dedent the code body so configcheck/pglast see clean text.
                 stripped_lines = []
@@ -56,7 +57,8 @@ def verify(binary):
                         if cmd in code:
                             found = True
                     if not found:
-                        print(code)
+                        print(f"Error in {file}:")
+                        print(original)
                         raise e
 
 def check_file(binary, kind, content):