Skip to content

fix(#8): dialect-neutral placeholders (S4.1) and parameter type mapping (S5) #15

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ssilvius merged 2 commits into from
Aug 3, 2026
Merged

fix(#8): dialect-neutral placeholders (S4.1) and parameter type mapping (S5) #15

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
b5551af
fix(spec): make S4.1 placeholders and S5 type mapping dialect-neutral
ssilvius Aug 3, 2026
55fa124
chore: retrigger CI (spec-sanity landed after this branch)
ssilvius Aug 3, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 13 additions & 9 deletions SPEC.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,9 @@ A request body MUST be a JSON object containing **either** a `sql` field (single
```

- `sql` (REQUIRED, string) — the SQL statement.
- `params` (OPTIONAL, array) — positional parameters, in the order of `?` placeholders in `sql`. Defaults to `[]`.
- `params` (OPTIONAL, array) — positional parameters, in the order of the positional placeholders in `sql`. Defaults to `[]`.

The placeholder syntax itself is the server's, not this spec's: http-sql does not parse or rewrite `sql`, so the client MUST write placeholders in the syntax its target server accepts. (Non-normative: `?` in SQLite and MySQL, `$1` in PostgreSQL. The examples in this document use `?`.)

### 4.2 Batch

Expand All @@ -67,15 +69,17 @@ Servers MAY reject batches that exceed a server-defined statement count with HTT

## 5. Parameter types

Positional parameters use JSON values. The mapping to SQL types is:
Positional parameters use JSON values. Each JSON value MUST be bound as the server's corresponding SQL type:

| JSON value | Bound as |
|--------------------|--------------------------|
| string | the server's text type |
| integer number | the server's integer type |
| floating-point | the server's real type |
| boolean | the server's boolean type |
| null | SQL `NULL` |

| JSON value | SQL type |
|--------------------|-------------------|
| string | TEXT |
| integer number | INTEGER |
| floating-point | REAL |
| boolean | INTEGER (1 or 0) |
| null | NULL |
The type names above are semantic, not literal SQL type names; each server maps them onto its own type system. Where a server's engine lacks one of these types natively, how it represents the value is an implementation detail of that server — for example, SQLite has no boolean type, so SQLite-backed servers store booleans as `1` and `0`. Servers MUST NOT assume any particular engine's type system on the client's behalf.

For values that cannot be represented as a JSON primitive (binary blobs, integers outside JS-safe range, dates as strings of a specific format), a **tagged value** is used:

Expand Down
Loading