fix(tables): keep the legacy numeric fallback for unknown filter fields

A backward-compatibility check on the whole change turned this up. Making the
range-comparison cast registry-driven fixed the real bug — a text-shaped type
emitting `(data->>'email')::numeric` and 500ing the rows query — but it also
swept in fields with NO schema entry, which resolve to `string` through
`columnTypeById`'s fallback and so began comparing lexicographically.

Ad-hoc numeric fields have always compared numerically there, and `'10' > '5'`
is false as text, so a saved filter on a field that is not in the schema (a
typo, or a column since removed) would quietly return a different row set with
no error at all.

An absent column type is now distinguished from a known text type: unknown
keeps `::numeric` and its operand validation exactly as before, while a known
type still answers from the registry. Both cases are pinned by tests.

Author: waleedlatif1

apps/sim/lib/table/__tests__/sql.test.ts

@@ -114,16 +114,13 @@ describe('SQL Builder', () => {
       expect(out).not.toContain('::timestamp')
     })
 
-    it('compares an unknown column type as TEXT, never with an invented cast', () => {
-      // An unknown type resolves to `string` (`columnTypeById`'s documented
-      // fallback), and `string` compares as text. The `?? 'numeric'` default
-      // this replaced was reached by every type whose `jsonbCast` is null —
-      // so a range filter on an `email` column emitted
-      // `(data->>'email')::numeric`, which Postgres errors on at the first
-      // non-numeric row and takes the whole rows query down with it.
+    it('falls back to ::numeric for a field with no schema entry', () => {
+      // An UNKNOWN field keeps the legacy numeric default — ad-hoc numeric
+      // fields have always compared numerically, and switching them to
+      // lexicographic ordering would change a saved filter's row set silently.
+      // A known text-shaped type is a different question; see the case below.
       const out = render(buildFilterClause({ score: { $gte: 5 } }, TABLE, NO_COLUMNS))
-      expect(out).toContain(`${TABLE}.data->>'score' >= `)
-      expect(out).not.toContain('::numeric')
+      expect(out).toContain(`(${TABLE}.data->>'score')::numeric >= `)
       expect(out).not.toContain('::timestamp')
     })
 
@@ -381,14 +378,10 @@ describe('SQL Builder', () => {
       ).toThrow(/column "birthDate" \(date\) requires a date string, got number/)
     })
 
-    it('accepts a string on an unknown column, which compares as text', () => {
-      // Previously threw, because an unknown type fell through to a numeric
-      // cast that then demanded a numeric operand. Text comparison has no such
-      // requirement, and refusing a string on a column that renders as text
-      // was the wrong answer.
+    it('throws when $lt on an unknown column (numeric fallback) receives a string', () => {
       expect(() =>
         buildFilterClause({ score: { $lt: 'high' } } as Filter, TABLE, NO_COLUMNS)
-      ).not.toThrow()
+      ).toThrow(/requires a number, got string/)
     })
 
     it('accepts valid number on number column', () => {

apps/sim/lib/table/sql.ts

@@ -834,6 +834,19 @@ function buildComparisonClause(
   columnType: ColumnType | undefined
 ): SQL {
   const escapedField = field.replace(/'/g, "''")
+
+  // A field with NO schema entry keeps the legacy `::numeric` default. It is
+  // not a text-shaped column — it is an unknown one, and ad-hoc numeric fields
+  // have always compared numerically here. Falling through to the registry's
+  // `string` fallback would silently switch them to LEXICOGRAPHIC ordering,
+  // where `'10' > '5'` is false — a saved filter would start returning a
+  // different row set with no error.
+  if (columnType === undefined) {
+    validateComparisonValue(field, columnType, 'numeric', value)
+    const cell = sql.raw(`(${tableName}.data->>'${escapedField}')::numeric`)
+    return sql`${cell} ${sql.raw(operator)} ${value}`
+  }
+
   const definition = columnTypeById(columnType)
 
   if (!definition.orderable) {
@@ -842,10 +855,10 @@ function buildComparisonClause(
     )
   }
 
-  // `jsonbCast === null` MEANS text comparison is correct — for `string` and
-  // for every other text-shaped type. Reading the registry rather than testing
-  // for `'string'` is what stops a new type falling past this into the cast
-  // below: `(data->>'email')::numeric` errors in Postgres on the first
+  // For a KNOWN type, `jsonbCast === null` means text comparison is correct —
+  // for `string` and for every other text-shaped type. Reading the registry
+  // rather than testing for `'string'` is what stops a new type falling into
+  // the cast below: `(data->>'email')::numeric` errors in Postgres on the first
   // non-numeric row, taking the whole rows query down with it.
   const cast = definition.jsonbCast
   if (cast === null) {