Datetime in Trino row_condition is bound as VARCHAR, causing TIMESTAMP type mismatch

[hsanslavillepro]

Trino row condition binds Python datetime as VARCHAR

Hi everyone,

I am using Great Expectations with Trino and a TableAsset.

When I use a Python datetime in a row_condition, the value is sent to Trino as a VARCHAR instead of a TIMESTAMP.

Environment

• Great Expectations: 1.18.2
• Python: 3.11
• Database: Trino
• Expectation: ExpectTableRowCountToBeBetween

Code

from datetime import datetime

import great_expectations as gx
from great_expectations.expectations.row_conditions import Column


min_allowed_datetime = datetime.now()

row_condition = (
    Column("date_insertion_clean")
    >= min_allowed_datetime
)

expectation = gx.expectations.ExpectTableRowCountToBeBetween(
    min_value=0,
    max_value=100,
    row_condition=row_condition,
)

The Trino column is:

date_insertion_clean TIMESTAMP(3)

Error

TrinoUserError(
    type=USER_ERROR,
    name=TYPE_MISMATCH,
    message="Cannot apply operator: timestamp(3) <= varchar(26)"
)

The generated SQL contains:

WHERE date_insertion_clean >= ?

The parameter is:

'2026-07-27T12:16:25.146982'

Although I pass a Python datetime, the parameter appears to be serialized and bound as a VARCHAR.

Expected behavior

The parameter should be bound as a SQL TIMESTAMP, or the generated SQL should use an explicit cast:

WHERE date_insertion_clean >= CAST(? AS TIMESTAMP)

Questions

1. Is this a known issue with Trino row conditions?
2. Is it fixed in Great Expectations 1.19.1 or a later version?
3. Is there a supported way to specify the SQL type or apply a CAST in a row_condition?

Thank you for your time ⌚ 🐛 🙏

[joshua-stauffer]

hey @hsanslavillepro, thanks for the bug report! It's a bug on our end, and should be straightforward to patch. I'll likely be able to ship the fix in this week's release, and will let you know when it goes out. Thanks again!

[hsanslavillepro]

Hello @joshua-stauffer thank you for you answer !

Let me know if you want me to test the fix and / or contribute to the MR.

Thank you 🙏

[hsanslavillepro]

@joshua-stauffer do you want me to create an issue to track the bug ?

[joshua-stauffer]

@hsanslavillepro I've converted this to an issue as #12042, and will close this thread in favor of that one. I took a closer look at this bug today, and discovered that it's related to #11566. During execution (like here) it shows up as a SQL type mismatch, and on persist it becomes a JSON round-trip mismatch. I'd like to find a solution that addresses the root cause, but need more time to consider the design. Once I settle on an approach I'll add it to the issue and ping you. If at that point you're interested in contributing the fix, I'm happy to assign the issue to you!

thanks again for the report.