remove superfluous prev/next page links

cljdoc adds these automatically now.

doc/all-the-options.md

@@ -107,5 +107,3 @@ The `transact` function and `with-transaction` macro accept the following option
 The `next.jdbc.plan/select!` function accepts the following specific option:
 
 * `:into` -- a data structure into which the selected result from a `plan` operation are poured; by default this is `[]`; could be any value that is acceptable as the first argument to `into`, subject to `into` accepting the sequence of values produced by the `plan` reduction.
-
-[<: Transactions](/doc/transactions.md) | [`datafy`, `nav`, and `:schema` :>](/doc/datafy-nav-and-schema.md)

doc/datafy-nav-and-schema.md

@@ -79,5 +79,3 @@ If you require `next.jdbc.datafy`, the `Datafiable` protocol is extended to seve
 See the Java documentation for these JDBC types for further details on what all the properties from each of these classes mean and which are `int`, `String`, or some other JDBC object type.
 
 In addition, requiring this namespace will affect how `next.jdbc.result-set/metadata` behaves inside the reducing function applied to the result of `plan`. Without this namespace loaded, that function will return a raw `ResultSetMetaData` object (which must not leak outside the reducing function). With this namespace loaded, that function will, instead, return a Clojure data structure describing the columns in the result set.
-
-[<: All The Options](/doc/all-the-options.md) | [Migration from `clojure.java.jdbc` :>](/doc/migration-from-clojure-java-jdbc.md)

doc/friendly-sql-functions.md

@@ -262,5 +262,3 @@ By default, for compatibility with their default adapter (`clojure.java.jdbc`),
 (character-by-id ds {:id 1})
 ;;=> #:CHARACTERS{:ID 1, :NAME "Westley", :SPECIALTY "love", :CREATED_AT #inst "2019-09-27T18:52:54.413000000-00:00"}
 ```
-
-[<: Getting Started](/doc/getting-started.md) | [Tips & Tricks :>](/doc/tips-and-tricks.md)

doc/getting-started.md

@@ -673,5 +673,3 @@ A convenience function also exists to revert that instrumentation:
 ```clojure
 (specs/unstrument) ; undoes the instrumentation of all next.jdbc API functions
 ```
-
-[Friendly SQL Functions :>](/doc/friendly-sql-functions.md)

doc/migration-from-clojure-java-jdbc.md

@@ -123,5 +123,3 @@ These are mostly drawn from [Issue #5](https://github.com/seancorfield/next-jdbc
 * `with-transaction` can take a `:rollback-only` option, but there is no built-in way to change a transaction to rollback _dynamically_; either throw an exception (all transactions roll back on an exception) or call `.rollback` directly on the `java.sql.Connection` object (see [Manual Rollback Inside a Transactions](/doc/transactions.md#manual-rollback-inside-a-transaction) and the following section about save points),
 * `clojure.java.jdbc` implicitly allowed transactions to nest and just silently ignored the inner, nested transactions (so you only really had the top-level, outermost transaction); `next.jdbc` by default assumes you know what you are doing and so an inner (nested) transaction will commit or rollback the work done so far in outer transaction (and then when that outer transaction ends, the remaining work is rolled back or committed); `next.jdbc.transaction/*nested-tx*` is a dynamic var that can be bound to `:ignore` to get the same behavior as `clojure.java.jdbc`.
 * The extension points for setting parameters and reading columns are now `SettableParameter` and `ReadableColumn` protocols.
-
-[<: `datafy`, `nav`, and `:schema`](/doc/datafy-nav-and-schema.md)

doc/prepared-statements.md

@@ -142,5 +142,3 @@ There are several caveats around using batched parameters. Some JDBC drivers nee
 In addition, if the batch operation fails for a group of parameters, it is database-specific whether the remaining groups of parameters are used, i.e., whether the operation is performed for any further groups of parameters after the one that failed. The result of calling `execute-batch!` is a vector of integers. Each element of the vector is the number of rows affected by the operation for each group of parameters. `execute-batch!` may throw a `BatchUpdateException` and calling `.getUpdateCounts` (or `.getLargeUpdateCounts`) on the exception may return an array containing a mix of update counts and error values (a Java `int[]` or `long[]`). Some databases don't always return an update count but instead a value indicating the number of rows is not known (but sometimes you can still get the update counts).
 
 Finally, some database drivers don't do batched operations at all -- they accept `.executeBatch` but they run the operation as separate commands for the database rather than a single batched command.
-
-[<: Result Set Builders](/doc/result-set-builders.md) | [Transactions :>](/doc/transactions.md)

doc/result-set-builders.md

@@ -150,5 +150,3 @@ The default implementation of this protocol is for these two functions to return
 Remember that a protocol extension will apply to all code running in your application so with the above code **all** timestamp values coming from the database will be converted to `java.time.Instant` for all queries. If you want to control behavior across different calls, consider the adapters described above (`as-maps-adapter`, `as-arrays-adapter`, and `builder-adapter`, and think about using metadata to implement the `rs/ReadableColumn` protocol instead of extending it).
 
 Note that the converse, converting Clojure values to database-specific types is handled by the `SettableParameter` protocol, discussed in the next section ([Prepared Statements](/doc/prepared-statements.md#prepared-statement-parameters)).
-
-[<: Tips & Tricks](/doc/tips-and-tricks.md) | [Prepared Statements :>](/doc/prepared-statements.md)

doc/tips-and-tricks.md

@@ -459,5 +459,3 @@ If you are using `plan`, you'll most likely be accessing columns by just the lab
         []
         (jdbc/plan ds ["select * from some_table"]))
 ```
-
-[<: Friendly SQL Functions](/doc/friendly-sql-functions.md) | [Result Set Builders :>](/doc/result-set-builders.md)

doc/transactions.md

@@ -94,5 +94,3 @@ transactions in the code under test.
 * `next.jdbc.transaction/*nested-tx*` is initially set to `:allow` which allows nested calls but makes them overlap (as described above),
 * `(binding [next.jdbc.transaction/*nested-tx* :ignore] ...)` provides the same behavior as `clojure.java.jdbc` where nested calls are essentially ignored and only the outermost transaction takes effect,
 * `(binding [next.jdbc.transaction/*nested-tx* :prohibit] ...)` will cause any attempt to start a nested transaction to throw an exception instead; this could be a useful way to detect the potentially buggy behavior described above (for either `:allow` or `:ignore`).
-
-[<: Prepared Statements](/doc/prepared-statements.md) | [All The Options :>](/doc/all-the-options.md)