Arrays of custom-OID types (enum[], hstore[], etc.) decode to null

[aesslinger]

Describe the bug

extract.rs's extract_value dispatch only special-cases specific well-known Type::*_ARRAY constants (INT2_ARRAY, INT4_ARRAY, TEXT_ARRAY, VARCHAR_ARRAY, FLOAT4_ARRAY, FLOAT8_ARRAY, BOOL_ARRAY). Any array of a custom-OID element type — enum arrays, hstore arrays, domain arrays, etc. — falls through to the generic _ => try_get::<String> fallback, which fails and returns null.

The builtin driver (src-tauri/src/drivers/postgres/extract/) does not have this gap: its dispatch matches on Kind::Array(elem_type) generically (extract/mod.rs) and recurses into per-element extraction via extract/array.rs::try_extract_elem, which itself dispatches on the element's Kind (Simple, Enum, Range, Multirange, Domain, Composite). That means the builtin correctly decodes mood[] (enum array), hstore[], etc., while this plugin does not.

To Reproduce

Against a database with an enum type or hstore extension installed:

-- enum array
CREATE TYPE mood AS ENUM ('happy', 'sad');
SELECT ARRAY['happy'::mood, 'sad'::mood];
-- returns null instead of ["happy", "sad"]

-- hstore array
CREATE EXTENSION IF NOT EXISTS hstore;
SELECT ARRAY['a=>1'::hstore, 'b=>2'::hstore];
-- returns null instead of [{"a": "1"}, {"b": "2"}]

Root cause

src/extract.rs's extract_value matches on specific Type:: array constants rather than the generic Kind::Array(elem_type) pattern the builtin uses. There's no recursive per-element dispatch, so any array whose element type isn't one of the ~7 hardcoded array constants silently nulls out.

Discovered via

Found while auditing #71 (hstore scalar-column fix) for shortcuts — confirmed this is a pre-existing gap affecting all custom-OID array types, not specific to hstore. enum[] exhibits the identical symptom, verified against a live database.

Relevant Log Output

N/A — no error, just silent null.