import { type Type } from "../infer/types.js";
import type { FnRule } from "../infer/functions.js";
export declare const MYSQL_ALIASES: Record<string, string>;
export declare function mysqlParseType(text: string): Type;
/** MySQL literal forms (dev.mysql.com/doc/refman/8.4/en/literals.html). Numerics split on MySQL's
 *  exact-vs-approximate line (.../precision-math-numbers.html): a literal with a decimal point and
 *  no exponent (`3.5`, `.2`) is an EXACT-value DECIMAL; only the scientific-notation form (`1.2E3`)
 *  is an approximate-value DOUBLE — the same split snowflake/redshift/postgres/duckdb/trino encode
 *  (NOT sqlite, whose five storage classes have no DECIMAL, so its classifier's `double` there is
 *  correct for it and wrong here). A bare integer stays `int` (house convention across every
 *  dialect's classifier). TRUE/FALSE are documented synonyms for the integers 1/0
 *  (.../numeric-type-syntax.html "BOOL, BOOLEAN ... TINYINT(1)"), not a distinct boolean type. A
 *  hexadecimal literal (X'…' / 0x…) is, per its own syntax alone with no surrounding context, "a
 *  binary string" by default (.../hexadecimal-literals.html) — the numeric-context
 *  reinterpretation needs the call site, which this text-only classifier doesn't have, so it stays
 *  at the documented default rather than guessing. Bit-value literals (b'…' / 0b…) are left
 *  UNKNOWN: unlike hex literals, the docs don't name a context-free default
 *  (.../bit-value-literals.html), so classifying either way would be a guess. */
export declare function mysqlLiteral(text: string): Type;
export declare const MYSQL_FUNCTION_RETURNS: Record<string, FnRule>;