[Bug]: Cannot save datetime field in PostgreSQL

[frol]

Describe the bug

If I edit a datetime field value in PostgreSQL, I get the following error:

Update failed: error serializing parameter 0

PostgreSQL update context:
- table: "public"."monitored_accounts"
- column: "created_at" (timestamp with time zone)
- new value JSON type: string
- primary key: "account_id" JSON type string
- SQL: UPDATE "public"."monitored_accounts" SET "created_at" = $1 WHERE "account_id" = $2

To Reproduce

1. Use a table with datetime field
2. Edit the datetime value to any other value
3. "Submit" the changes

OS Version

MacOS 26

Tabularis Version

0.13.4

Relevant Log Output

[NewtTheWolf]

Thanks for the report @frol.

What I tried

Set up a matching table and ran the updates manually against Postgres (I'm on 16.14):

CREATE TABLE public.monitored_accounts (
    account_id  text PRIMARY KEY,
    created_at  timestamp with time zone NOT NULL
);
INSERT INTO public.monitored_accounts (account_id, created_at)
VALUES ('acc_1', '2024-01-15 10:30:00+00'),
       ('acc_2', '2024-06-30 23:59:59+02');

-- the update from your report
UPDATE public.monitored_accounts SET "created_at" = '2025-06-30T12:00:00+00:00' WHERE "account_id" = 'acc_1';
-- naive (no offset)
UPDATE public.monitored_accounts SET "created_at" = '2025-06-30 12:00:00' WHERE "account_id" = 'acc_1';
-- Z suffix
UPDATE public.monitored_accounts SET "created_at" = '2025-06-30T12:00:00Z' WHERE "account_id" = 'acc_2';
-- NULL (after dropping NOT NULL)
ALTER TABLE public.monitored_accounts ALTER COLUMN created_at DROP NOT NULL;
UPDATE public.monitored_accounts SET "created_at" = NULL WHERE "account_id" = 'acc_1';

All of these go through fine on my side, and editing the value via the in-app editor also submits without the error serializing parameter 0 you're seeing — so I can't reproduce it yet. That suggests it depends on the specific input or environment.

Question for you

To narrow it down, could you tell me:

1. The exact value you typed into the field when it failed (copy it verbatim).
2. Which PostgreSQL version are you running? (SELECT version();) — I'm on 16.14.
3. Can you reproduce the error with the table and queries above?
4. Does it also fail for a timestamp without time zone column, or only with time zone?
5. The full error text — please expand the "show details" section and paste anything additional there.

[NewtTheWolf]

Update: I managed to reproduce it through the in-app editor on my side now. Looking into it — the failure is in our PostgreSQL parameter binding path (the edited value is sent as a JSON string and bound as text instead of being parsed for the timestamptz column). I'll follow up with a fix.

[NewtTheWolf]

Reproduced and root-caused.

Root cause — src-tauri/src/drivers/postgres/binding.rs, bind_pg_string.

The data grid editor sends every edited cell as a JSON string. bind_pg_string has coercion paths for boolean, numeric, raw-SQL functions, WKT geometry, UUID and arrays — but no path for date/time types. So an edited timestamp/timestamptz/date/time/interval value falls through to the default branch and is bound as a plain text parameter:

Ok(BoundValue {
    sql: format!("${}", placeholder_idx),
    param: Some(Box::new(s.to_string())),
})

tokio-postgres cannot serialize a Rust String to a temporal OID, hence error serializing parameter 0. The SQL itself is valid — running the same UPDATE directly against Postgres works; the failure is purely in our parameter binding.

Fix direction — add a temporal coercion path (mirroring the existing numeric/uuid handling): bind the string and wrap the placeholder in CAST($N AS <canonical temporal type>), letting PostgreSQL parse the literal. Cast target must be a fixed canonical type, never the raw column-type string. Affected types: timestamp, timestamp with time zone, date, time, time with time zone, interval.

Status: on the TODO, assigned to @NewtTheWolf.

[debba]

Fixed in 8015008 on feat/postgres-multi-database (will ship in the next release).

Root cause confirmed and extended: the fix direction in the thread above (cast the placeholder, e.g. CAST($N AS timestamptz)) is necessary but not sufficient — tokio-postgres resolves the placeholder's effective type to the cast target during Describe, so a bound String is still rejected client-side (error serializing parameter N) before PostgreSQL's own text-to-temporal parsing ever runs. Verified this live against a PostgreSQL 16 container.

The actual fix pins every bound parameter's wire type explicitly via prepare_typed/execute_typed (declaring it TEXT for the cast cases), so the client-side type check matches what's actually sent and PostgreSQL performs the real conversion server-side — exactly like a literal value in a plain SQL statement.

This also fixes the same root-cause bug for uuid-shaped string values going into a genuine uuid column (the CAST($N AS uuid) path), which turned out to be silently broken the same way despite #392.

Covered by new unit tests plus an ignored live-Postgres regression test (live_pg_update_record_handles_temporal_and_uuid_columns) that exercises the real update_record driver function against timestamptz, date, time, and uuid-PK columns.