@quereus/quereus 4.20.1 → 4.20.2

package/test/logic/06.5.4-declared-return-type-builtins.sqllogic

@@ -0,0 +1,288 @@
+-- declared-return-type-builtins.sqllogic
+-- Ticket 2-builtin-scalar-function-declared-return-types gave every built-in scalar
+-- function that used to ride the default an honest `returnType` (json.ts, datetime.ts,
+-- timespan.ts, plus random/randomblob/pow/power and like/glob). `json_extract` is the one
+-- deliberate holdout — genuinely polymorphic — and 06.5.3 covers that.
+--
+-- The declarations are supposed to change PLANS, not ANSWERS: a known return type routes
+-- comparisons through the specialized `compare-fast` / `compare-typed` paths and lets
+-- cross-type coercion fire, but the value each query produces must be the same. This file
+-- pins the answers on both sides of the category boundaries the declarations cross.
+--
+-- No `using memory`, so store mode exercises the persisted path too.
+
+create table drt (id integer primary key, j json, d text, ts timespan);
+insert into drt values (1, '{"a":"x"}', '2024-03-04', 'P3D');
+-- run
+
+-- ===================================
+-- 1. BOOLEAN-returning predicates compare against numbers as they always did
+-- ===================================
+-- json_valid used to type as ANY (BOOLEAN vs INTEGER now, ANY vs INTEGER before) — both
+-- routes end in the same numeric comparison, because boolean is a NUMERIC storage class.
+select json_valid('{}') = 1 as r;
+→ [{"r":true}]
+
+select json_valid(j) = 1 as r from drt;
+→ [{"r":true}]
+
+select json_valid('not json') = 0 as r;
+→ [{"r":true}]
+
+select json_schema(j, 'string') = 0 as r from drt;
+→ [{"r":true}]
+
+select IsISODate('2024-03-04') as a, IsISODate('04/03/2024') as b;
+→ [{"a":true,"b":false}]
+
+select IsISODateTime('2024-03-04T05:06:07') as a, IsISODateTime('2024-03-04') as b;
+→ [{"a":true,"b":false}]
+
+-- like/glob stay NULLABLE booleans: a null operand is NULL, not false.
+select like('obj%', 'object') as a, glob('obj*', 'object') as b;
+→ [{"a":true,"b":true}]
+
+select like('obj%', null) as a, glob(null, 'object') as b;
+→ [{"a":null,"b":null}]
+
+-- ===================================
+-- 2. INTEGER-returning functions
+-- ===================================
+select timespan_days(timespan('P3D')) = 3 as r;
+→ [{"r":true}]
+
+select timespan_days(ts) = 3 as r from drt;
+→ [{"r":true}]
+
+select timespan_hours(timespan('PT5H')) as r;
+→ [{"r":5}]
+
+select json_array_length('[1,2,3]') as r;
+→ [{"r":3}]
+
+-- The point of declaring INTEGER: the numeric↔textual arm of insertCrossTypeCoercion now
+-- has something to key on, so a numeric-looking string literal is cast instead of being
+-- compared across storage classes. This was FALSE while these functions typed as ANY.
+select json_array_length('[1,2,3]') = '3' as r;
+→ [{"r":true}]
+
+select epoch_s('2024-03-04') as r;
+→ [{"r":1709510400}]
+
+select epoch_s(d) = '1709510400' as r from drt;
+→ [{"r":true}]
+
+select epoch_ms(d) = '1709510400000' as r from drt;
+→ [{"r":true}]
+
+select typeof(random()) as r;
+→ [{"r":"integer"}]
+
+-- ===================================
+-- 3. REAL-returning functions
+-- ===================================
+select pow(2, -1) as a, power(2, -1) as b;
+→ [{"a":0.5,"b":0.5}]
+
+select pow(2, 3) = '8' as r;
+→ [{"r":true}]
+
+select julianday('2024-03-04') as r;
+→ [{"r":2460373.5}]
+
+select epoch_s_frac('2024-03-04T00:00:00.500Z') as r;
+→ [{"r":1709510400.5}]
+
+-- timespan_seconds is REAL, not INTEGER like its six sibling component extractors: it
+-- folds the sub-second components into its result.
+select timespan_seconds('PT1.5S') as r;
+→ [{"r":1.5}]
+
+select timespan_total_seconds('P1D') as a, timespan_total_hours('P1D') as b;
+→ [{"a":86400,"b":24}]
+
+-- sqrt is REAL for the same reason as pow: Math.sqrt is not closed over the integers, so
+-- inferring the argument's type would claim INTEGER for a value like sqrt(2). The write
+-- path acts on that claim — see section 7.
+select sqrt(2) as a, typeof(sqrt(2)) as t;
+→ [{"a":1.4142135623730951,"t":"real"}]
+
+select sqrt(4) = '2' as r;
+→ [{"r":true}]
+
+-- ===================================
+-- 4. TEXT-returning functions
+-- ===================================
+select json_type(j) as r from drt;
+→ [{"r":"object"}]
+
+select json_quote(j) = '{"a":"x"}' as r from drt;
+→ [{"r":true}]
+
+select typeof(json_quote(j)) as r from drt;
+→ [{"r":"text"}]
+
+select strftime('%Y', d) = '2024' as r from drt;
+→ [{"r":true}]
+
+-- A TEXT-typed value is not a number: the numeric builtins reject it at plan time, the
+-- same way they reject a text column. Convert first with integer()/real().
+select abs(strftime('%Y', d)) as r from drt;
+-- error: Invalid argument types for function abs
+
+select abs(integer(strftime('%Y', d))) as r from drt;
+→ [{"r":2024}]
+
+-- ===================================
+-- 5. BLOB-returning randomblob
+-- ===================================
+select typeof(randomblob(4)) as t, length(randomblob(4)) as n;
+→ [{"t":"blob","n":4}]
+
+select randomblob(0) = randomblob(0) as r;
+→ [{"r":true}]
+
+-- ===================================
+-- 6. JSON-returning functions compare structurally against a JSON column
+-- ===================================
+-- Both sides now declare JSON, so `=` routes through JSON_TYPE.compare (structural)
+-- rather than the object-cast arm. The answer must not move.
+select json_object('a','x') = j as r from drt;
+→ [{"r":true}]
+
+select json_array(1,2) = json_array(1,2) as r;
+→ [{"r":true}]
+
+select json_set(j, '$.b', 1) = json_object('a','x','b',1) as r from drt;
+→ [{"r":true}]
+
+select json_remove(json_object('a','x','b',1), '$.b') = j as r from drt;
+→ [{"r":true}]
+
+select json_insert(j, '$.b', 2) = json_object('a','x','b',2) as r from drt;
+→ [{"r":true}]
+
+select json_replace(j, '$.a', 'y') = json_object('a','y') as r from drt;
+→ [{"r":true}]
+
+select typeof(json_object('a','x')) as r;
+→ [{"r":"json"}]
+
+-- A JSON mutator can yield a JSON *scalar* rather than an object. typeof reports the
+-- storage class of a JSON scalar, so it reads 'integer' — the same answer `json('5')`
+-- gives, and unchanged by the JSON declaration.
+select json_set('{}', '$', 5) as r, typeof(json_set('{}', '$', 5)) as t, typeof(json('5')) as j;
+→ [{"r":5,"t":"integer","j":"integer"}]
+
+-- ===================================
+-- 7. Write path: convert exactly once
+-- ===================================
+-- A JSON-declared function's result matches a JSON column's type exactly, so
+-- buildRowCoercion skips conversion and the native object is stored directly — no
+-- second parse. Storing text (json_quote) into the same column DOES convert, once.
+create table jw (id integer primary key, j json);
+insert into jw(id, j) select 1, json_object('a','x');
+insert into jw(id, j) select 2, json_quote(j) from drt;
+-- run
+
+select id, typeof(j) as t from jw order by id;
+→ [{"id":1,"t":"json"},{"id":2,"t":"json"}]
+
+select count(*) as c from jw where j = json_object('a','x');
+→ [{"c":2}]
+
+-- The mirror case: a REAL-declared result into an INTEGER column does NOT match the
+-- column type, so conversion runs and the stored value is a whole number. Declaring the
+-- argument's type instead would skip the conversion and leave 1.4142135623730951 in an
+-- INTEGER column.
+create table iw (id integer primary key, v integer);
+insert into iw(id, v) select 1, sqrt(2);
+insert into iw(id, v) select 2, pow(2, 0.5);
+-- run
+
+select id, v, typeof(v) as t from iw order by id;
+→ [{"id":1,"v":1,"t":"integer"},{"id":2,"v":1,"t":"integer"}]
+
+-- Nullability is declared, not enforced: a nullable BOOLEAN that resolves to NULL still
+-- meets the column's NOT NULL check at runtime rather than slipping past it.
+create table bw (id integer primary key, ok boolean not null);
+insert into bw(id, ok) select 1, json_valid('{}');
+-- run
+
+select ok from bw;
+→ [{"ok":true}]
+
+insert into bw(id, ok) select 2, like('a%', null);
+-- error: NOT NULL constraint failed: bw.ok
+
+-- ===================================
+-- 8. The variadic date/time/datetime functions declare TEXT, not DATE/TIME/DATETIME
+-- ===================================
+-- They emit SQLite's display spelling, which is NOT the canonical stored spelling of the
+-- temporal types: datetime() uses a space separator and time(...,'subsec') always emits
+-- three fractional digits. Declaring the temporal type would make the write path treat
+-- those as already-canonical and store the display spelling, which the temporal types
+-- compare as binary text — so a canonically-written value would stop matching. TEXT keeps
+-- the conversion, and these are the values that conversion must produce.
+select date('2024-03-04', '+1 day') as a, time('12:00:00', 'subsec') as b,
+	datetime('2024-03-04 05:06:07', '+1 day') as c;
+→ [{"a":"2024-03-05","b":"12:00:00.000","c":"2024-03-05 05:06:07"}]
+
+create table dw (id integer primary key, dd date, tt time, dt datetime);
+insert into dw(id, dd, tt, dt)
+	select 1, date('2024-03-04', '+1 day'), time('12:00:00', 'subsec'),
+		datetime('2024-03-04 05:06:07', '+1 day');
+-- run
+
+-- Stored in each type's canonical spelling — 'T' separator, trimmed milliseconds.
+select dd, tt, dt from dw;
+→ [{"dd":"2024-03-05","tt":"12:00:00","dt":"2024-03-05T05:06:07"}]
+
+select dt = '2024-03-05T05:06:07' as r from dw;
+→ [{"r":true}]
+
+-- Comparing the function's own result against a literal is unchanged.
+select date('2024-03-04', '+1 day') = '2024-03-05' as r;
+→ [{"r":true}]
+
+select date(d, '+1 day') = '2024-03-05' as r from drt;
+→ [{"r":true}]
+
+-- Temporal arithmetic over the result still works — it is dispatched on the runtime
+-- value's shape, not on the declared type.
+select date('2024-03-04', '+1 day') + 'P1D' as r;
+→ [{"r":"2024-03-06"}]
+
+-- ===================================
+-- 9. The plans actually changed — the point of the whole exercise
+-- ===================================
+-- Sections 1-8 prove the answers did not move; this one proves the declarations bought
+-- something. `scheduler_program()` exposes each instruction's note, and the comparison
+-- emitter tags itself with the path it chose (runtime/emit/binary.ts):
+--   compare-fast  — both operands the same category (numeric/textual), no coercion
+--   compare-typed — both operands the same logical type with semantic ordering (JSON)
+--   compare       — the generic path: temporal check plus coercion
+-- Every one of these read `compare` while the function rode the ANY default.
+select count(*) as c from scheduler_program('select json_quote(j) = ''text'' from drt')
+	where description = '=(compare-fast)';
+→ [{"c":1}]
+
+select count(*) as c from scheduler_program('select epoch_s(d) = 1 from drt')
+	where description = '=(compare-fast)';
+→ [{"c":1}]
+
+select count(*) as c from scheduler_program('select json_object(''a'',''x'') = j from drt')
+	where description = '=(compare-typed)';
+→ [{"c":1}]
+
+-- json_extract is the deliberate ANY holdout, so it still takes the generic path. This is
+-- the control: it is what every row above looked like before the declarations landed.
+select count(*) as c from scheduler_program('select json_extract(j, ''$.a'') = ''x'' from drt')
+	where description = '=(compare)';
+→ [{"c":1}]
+
+drop table bw;
+drop table iw;
+drop table dw;
+drop table jw;
+drop table drt;

package/test/logic/06.6-aggregate-extended.sqllogic

@@ -0,0 +1,78 @@
+-- aggregate-extended.sqllogic - Testing aggregate functions not covered in 07-aggregates
+
+-- Create test table
+create table agg_ext (id integer primary key, val real null, grp text);
+insert into agg_ext values (1, 10.0, 'a'), (2, 20.0, 'a'), (3, 30.0, 'a'), (4, 40.0, 'b'), (5, 50.0, 'b'), (6, null, 'b');
+
+-- total (returns 0.0 for empty set, unlike sum which returns null)
+select total(val) from agg_ext;
+→ [{"total(val)":150}]
+
+-- total vs sum with empty set
+create table empty_t (id integer primary key, x real null);
+select total(x), sum(x) from empty_t;
+→ [{"total(x)":0,"sum(x)":null}]
+drop table empty_t;
+
+-- statistical aggregates: population variance
+select var_pop(val) from agg_ext where grp = 'a';
+→ [{"var_pop(val)":66.66666666666669}]
+
+-- sample variance
+select var_samp(val) from agg_ext where grp = 'a';
+→ [{"var_samp(val)":100}]
+
+-- population standard deviation
+select stddev_pop(val) from agg_ext where grp = 'a';
+→ [{"stddev_pop(val)":8.16496580927726}]
+
+-- var_samp with single value returns null
+select var_samp(val) from agg_ext where id = 1;
+→ [{"var_samp(val)":null}]
+
+-- string_concat aggregate
+select string_concat(grp) from agg_ext;
+→ [{"string_concat(grp)":"a,a,a,b,b,b"}]
+
+drop table agg_ext;
+
+-- total with null-only values
+create table null_t (id integer primary key, x real null);
+insert into null_t values (1, null), (2, null);
+select total(x), sum(x) from null_t;
+→ [{"total(x)":0,"sum(x)":null}]
+drop table null_t;
+
+-- var_pop with empty set returns null
+create table empty_var (id integer primary key, x real null);
+select var_pop(x) from empty_var;
+→ [{"var_pop(x)":null}]
+drop table empty_var;
+
+-- declared return types for the json/string aggregate builtins, pinned via the
+-- maintained-table strict shape gate (declared column types must equal the
+-- body-derived ones: json_group_array/json_group_object → json null,
+-- string_concat → text null)
+create table agg_rt (id integer primary key, grp text not null, v text not null);
+insert into agg_rt values (1, 'a', 'x'), (2, 'a', 'y'), (3, 'b', 'z');
+-- the PK column pins `collate binary` so the declared collation matches the
+-- body-derived one under both suites (the store's key collation defaults to NOCASE)
+create table agg_rt_mt (grp text not null collate binary primary key, ja json null, jo json null, sc text null)
+	maintained as select grp, json_group_array(v) as ja, json_group_object(v, id) as jo, string_concat(v) as sc from agg_rt group by grp;
+select grp, ja, jo, sc from agg_rt_mt order by grp;
+→ [{"grp":"a","ja":["x","y"],"jo":{"x":1,"y":2},"sc":"x,y"},{"grp":"b","ja":["z"],"jo":{"z":3},"sc":"z"}]
+
+-- a declared REAL column for a json aggregate is now a shape error (the old
+-- implicit default derivation)
+create table agg_rt_bad (grp text not null collate binary primary key, ja real null)
+	maintained as select grp, json_group_array(v) as ja from agg_rt group by grp;
+-- error: body derives type
+
+-- maintenance keeps the json/text columns consistent (storage round-trip
+-- through the backing under the JSON type's hooks)
+insert into agg_rt values (4, 'b', 'w');
+select ja, jo, sc from agg_rt_mt where grp = 'b';
+→ [{"ja":["z","w"],"jo":{"z":3,"w":4},"sc":"z,w"}]
+
+drop table agg_rt_mt;
+drop table agg_rt;

package/test/logic/06.7-json-extended.sqllogic

@@ -0,0 +1,53 @@
+-- json-extended.sqllogic - Testing JSON functions not covered in 06-builtin_functions
+
+-- json_patch replace
+select json_patch('{"a":1,"b":2}', '[{"op":"replace","path":"/a","value":3}]');
+→ [{"json_patch('{\"a\":1,\"b\":2}', '[{\"op\":\"replace\",\"path\":\"/a\",\"value\":3}]')":{"a":3,"b":2}}]
+
+-- json_patch add
+select json_patch('{"a":1}', '[{"op":"add","path":"/b","value":2}]');
+→ [{"json_patch('{\"a\":1}', '[{\"op\":\"add\",\"path\":\"/b\",\"value\":2}]')":{"a":1,"b":2}}]
+
+-- json_patch remove
+select json_patch('{"a":1,"b":2}', '[{"op":"remove","path":"/b"}]');
+→ [{"json_patch('{\"a\":1,\"b\":2}', '[{\"op\":\"remove\",\"path\":\"/b\"}]')":{"a":1}}]
+
+-- json_extract with path
+select json_extract('{"a":1,"b":2}', '$.a');
+→ [1]
+
+-- json_array_length with nested path
+select json_array_length('{"items":[1,2,3]}', '$.items');
+→ [3]
+
+-- json_array_length with non-array returns 0
+select json_array_length('{"a":1}');
+→ [0]
+
+-- json_set creates new keys
+select json_set('{"a":1}', '$.b', 'new');
+→ [{"a":1,"b":"new"}]
+
+-- json_insert does NOT overwrite existing
+select json_insert('{"a":1}', '$.a', 99);
+→ [{"a":1}]
+
+-- json_replace does NOT create new keys
+select json_replace('{"a":1}', '$.b', 99);
+→ [{"a":1}]
+
+-- NULL handling
+select json_valid(null), json_type(null), json_extract(null, '$.a');
+→ [{"json_valid(null)":false,"json_type(null)":"null","json_extract(null, '$.a')":null}]
+
+-- json_array_length of empty array
+select json_array_length('[]');
+→ [0]
+
+-- json_set overwrite existing
+select json_set('{"a":1}', '$.a', 99);
+→ [{"a":99}]
+
+-- json_remove non-existent path (no change)
+select json_remove('{"a":1}', '$.b');
+→ [{"a":1}]

package/test/logic/06.8-json-path-operators.sqllogic

@@ -0,0 +1,99 @@
+-- json-path-operators.sqllogic - Testing -> and ->> JSON path operators
+
+-- Basic -> with full JSON path
+select '{"a":1}' -> '$.a';
+→ [1]
+
+-- -> with nested path
+select '{"a":{"b":2}}' -> '$.a.b';
+→ [2]
+
+-- -> with string shorthand (auto-prepends $.)
+select '{"name":"alice"}' -> 'name';
+→ ["alice"]
+
+-- -> with integer shorthand (array index)
+select '[10,20,30]' -> 0;
+→ [10]
+
+select '[10,20,30]' -> 2;
+→ [30]
+
+-- -> extracts nested objects as native JSON
+select '{"a":[1,2]}' -> '$.a';
+→ [[1,2]]
+
+-- ->> returns TEXT (using alias for clean output)
+select '{"a":"hello"}' ->> '$.a' as val;
+→ [{"val":"hello"}]
+
+-- ->> coerces number to TEXT
+select '{"a":42}' ->> '$.a' as val;
+→ [{"val":"42"}]
+
+-- ->> renders an array as JSON text (one value-to-text rule, src/util/value-text.ts
+-- — this used to be the JS Array.toString() spelling '1,2')
+select '{"a":[1,2]}' ->> '$.a' as val;
+→ [{"val":"[1,2]"}]
+
+-- ->> with string shorthand
+select '{"x":"y"}' ->> 'x' as val;
+→ [{"val":"y"}]
+
+-- ->> with integer shorthand
+select '["a","b"]' ->> 1 as val;
+→ [{"val":"b"}]
+
+-- Chained -> operators
+select '{"a":{"b":{"c":3}}}' -> 'a' -> 'b' -> 'c';
+→ [3]
+
+-- NULL propagation
+select null -> '$.a';
+→ [null]
+
+select null ->> '$.a' as val;
+→ [{"val":null}]
+
+-- Non-existent path returns NULL
+select '{"a":1}' -> '$.b';
+→ [null]
+
+-- -> with table data
+create table jdoc (id integer primary key, data text);
+insert into jdoc values (1, '{"name":"alice","age":30}'), (2, '{"name":"bob","age":25}');
+
+select data -> 'name' from jdoc order by id;
+→ ["alice","bob"]
+
+select data ->> 'age' as age from jdoc where id = 1;
+→ [{"age":"30"}]
+
+-- -> with aliased result
+select data -> 'name' as person_name from jdoc order by id;
+→ [{"person_name":"alice"},{"person_name":"bob"}]
+
+-- -> in WHERE clause with subexpression
+select id from jdoc where cast(data -> 'name' as text) = 'bob';
+→ [{"id":2}]
+
+-- ->> in WHERE clause (returns text directly, no cast needed)
+select id from jdoc where data ->> 'name' = 'bob';
+→ [{"id":2}]
+
+-- Mixed -> and ->> chaining
+select '{"a":{"b":"deep"}}' -> 'a' ->> 'b' as val;
+→ [{"val":"deep"}]
+
+-- -> with boolean value
+select '{"t":true}' -> 't';
+→ [true]
+
+-- -> with JSON null value (distinct from SQL NULL for non-existent path)
+select '{"n":null}' -> 'n';
+→ [null]
+
+-- ->> with nested object returns the document's own text (one value-to-text rule,
+-- src/util/value-text.ts — this used to be the placeholder '[object Object]')
+select '{"a":{"x":1}}' ->> 'a' as val;
+→ [{"val":"{\"x\":1}"}]

package/test/logic/06.9-json-canonical-key.sqllogic

@@ -0,0 +1,65 @@
+-- json-canonical-key.sqllogic
+-- Hash/encoded keys must agree with the JSON value comparator (deepCompareJson):
+-- values that compare equal key alike, values that compare unequal key apart.
+-- No `using memory`, so store mode exercises the persisted byte-key path too.
+
+-- Distinct JSON objects form distinct groups. A PK on `id` leaves the scan ordered
+-- by id, so GROUP BY on the unsorted `j` picks HashAggregate (the serializeKey path).
+-- Before the canonical-key fix every object collapsed to one 'o:[object Object]' bucket.
+create table jc_t (id integer primary key, j json);
+insert into jc_t values (1, '{"a":1}'), (2, '{"a":2}'), (3, '{"b":9}');
+-- run
+
+select count(*) as groups from (select j from jc_t group by j);
+→ [{"groups":3}]
+
+-- Reorder-equal objects ({a:1,b:2} == {b:2,a:1}) group and de-dup together.
+create table jc_reorder (id integer primary key, j json);
+insert into jc_reorder values (1, '{"a":1,"b":2}'), (2, '{"b":2,"a":1}'), (3, '{"a":1,"b":2}');
+-- run
+
+select count(*) as groups from (select j from jc_reorder group by j);
+→ [{"groups":1}]
+
+select count(*) as c from (select distinct j from jc_reorder);
+→ [{"c":1}]
+
+-- Array element order stays significant — [1,2] and [2,1] are distinct groups.
+create table jc_arr (id integer primary key, j json);
+insert into jc_arr values (1, '[1,2]'), (2, '[2,1]'), (3, '[1,2]');
+-- run
+
+select count(*) as groups from (select j from jc_arr group by j);
+→ [{"groups":2}]
+
+-- Equality join on a JSON key matches reorder-equal values across the two sides.
+create table jc_left (id integer primary key, j json);
+create table jc_right (id integer primary key, j json, tag text);
+insert into jc_left values (1, '{"a":1,"b":2}');
+insert into jc_right values (1, '{"b":2,"a":1}', 'hit');
+-- run
+
+select l.id as lid, r.tag as tag from jc_left l join jc_right r on l.j = r.j;
+→ [{"lid":1,"tag":"hit"}]
+
+-- JSON primary key: a reorder-equal insert conflicts with the existing key, so
+-- `insert or replace` replaces the row rather than adding a second one.
+create table jc_pk (id json primary key, n integer);
+insert into jc_pk values ('{"a":1,"b":2}', 10);
+insert or replace into jc_pk values ('{"b":2,"a":1}', 20);
+-- run
+
+select count(*) as c from jc_pk;
+→ [{"c":1}]
+
+-- The replacing row wins; the stored/displayed JSON stays insertion-order (the
+-- canonical form is used only to derive the key, never for storage or display).
+select id, n from jc_pk;
+→ [{"id":{"b":2,"a":1},"n":20}]
+
+-- A genuinely different JSON PK is a distinct row (no over-merge).
+insert into jc_pk values ('{"a":1,"c":3}', 30);
+-- run
+
+select count(*) as c from jc_pk;
+→ [{"c":2}]