Filters should not default to "contains"

Nobody has claimed this yet.

Just tossing in an issue for something that has bugged me for a while about Postico (and actually other SQL tools that I've used as well): the table filters default to selecting "contains" for any string column. This results in a "LIKE" query, which will do a full table scan even, I believe, on an indexed column. On a large table, that is painful... and often not what I wanted anyway.

The dbs I work in a lot have mostly UUID primary keys so I am constantly copying the id from one table and pasting it into a filter for another table. If I space out changing that "contains" filter selection to "is exactly" I am often kicking off a very long query... sometimes minutes. The Postico UI does allow me to change the filter and fire off the corrected query without waiting for the bad one to complete, but I assume that my db server is still left chewing on the unintended long query... especially when I was just trying to load a specific record by its id.

It could even be a preference setting to say "any column name that ends in _id is treated as a discrete value and defaults to 'is exactly' for filtering". But really, why default to "contains" at all? I feel like, in my day-to-day work, I am mostly querying where a column equals a given value and only occasionally.

Would it be possible to (either by default or via a preference setting) make "is exactly" the default selection for filtering by a string column so that it works the same as other types (which default to "=")? Thanks!

No file or test is named in the issue. Start by locating the table-filter UI and the logic that selects operators for string columns, then trace how that choice becomes a SQL query. Done means string filters default to “is exactly,” or the requested preference behavior is clearly implemented and verified without triggering the unintended broad query.

Written by the indexing model from the issue text.