sea-orm-cli generates incorrect model for Postgres database containing 'tsvector' columns

Discussed in https://github.com/SeaQL/sea-orm/discussions/1880

^{Originally posted by flyaruu February 18, 2023}

Description

I'm using a postgres data model I tend to use for demos (some fictional data about movie rentals), and one of the tables has a column of type 'tsvector'

When I generate the ORM source, it looks like this:

#[sea_orm(column_type = "custom(\"tsvector\")")]
pub fulltext: String,

(The data + data model is open source, available here: but I don't think it is anything special.

When querying a record of this type I get this panic:

thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: Query(SqlxError(ColumnDecode { index: "\"fulltext\"", source: "mismatched types; Rust type `core::option::Option<alloc::string::String>` (as SQL type `TEXT`) is not compatible with SQL type `tsvector`" }))',

So it looks like String isn't the right type, but I'm unsure what is, and if sqlx supports it at all. I can comment out this column for now, then it all works.

But I'd say it would be better to ignore this type, as it breaks the entire table.

Steps to Reproduce

1. Take a database containing a tsvector column (e.g. the docker image I reference)
2. Generate a model using sea-orm-cli
3. Query one record (I did a find_by_id, but I don't think it matters)
4. Panic!

Expected Behavior

The result of that type

Actual Behavior

A panic

Reproduces How Often

Always

Versions

├── sea-orm v0.11.0
│   ├── sea-orm-macros v0.11.0 (proc-macro)
│   ├── sea-query v0.28.3
│   │   ├── sea-query-derive v0.3.0 (proc-macro)
│   ├── sea-query-binder v0.3.0
│   │   ├── sea-query v0.28.3 (*)
│   ├── sea-strum v0.23.0
│   │   └── sea-strum_macros v0.23.0 (proc-macro)

Start with the sea-orm-cli model generation flow and reproduce the issue against a PostgreSQL table containing a tsvector column, then query the generated model. Compare the generated String mapping with the reported SQLx decode error; done means generation no longer makes the table fail when this column is queried, either by supporting the type or safely ignoring it.