How to review CSV to SQL INSERT statements

The first parsed row supplies the INSERT column list. Every later row supplies values in that same position order. The generator does not query a database, so a header named `full name` is quoted as an identifier when that option is on; it does not prove that a column with that name exists or that its type accepts the generated literal.

CSV parsing handles quoted commas, doubled quotes and quoted line breaks before SQL generation. Headers are trimmed, blanks become positional column_N names, and repeated names gain suffixes. A pre-existing suffix can still collide: id,id,id_2 becomes id,id_2,id_2. The generator preserves that duplicate column list rather than validating a schema. Missing cells become blank input; extra cells beyond header width are discarded without a dedicated ragged-row warning here. Validate row widths and headers before generating SQL.

The table name is one identifier string, not a SQL expression. With identifier quoting enabled, a value such as `public.users` is quoted as one identifier (`"public.users"` in PostgreSQL-style quoting), not split into schema `public` and table `users`. Use the actual table name expected by your database or generate separate SQL after choosing the correct connection and schema. The processor defaults to my_table and one INSERT per row; a blank trimmed table name also falls back to my_table.

The dialect option changes identifier quotes only: PostgreSQL and the generic SQL form use double quotes, MySQL and MariaDB use backticks, and Transact-SQL uses square brackets. These quotes protect identifier spelling and reserved words; they do not translate data types, add a schema, validate a table, or make the emitted statement portable to every database advertised by the formatter.

Quote table and column names unless you deliberately control simple identifiers and know the target dialect’s folding rules. Quoting preserves the header spelling, which can be useful for a mixed-case or reserved header, but it also means a PostgreSQL header `UserId` refers exactly to `UserId`, not its unquoted lowercase equivalent.

Do not use a table-name field to add `WHERE`, a schema expression, a database name or SQL punctuation. Identifier quoting makes that text a literal identifier, which is safer than treating it as executable SQL but may produce an invalid identifier. Connection selection and schema qualification belong in your database workflow, not in this one input.

With type inference on, an empty CSV cell becomes SQL `NULL`; decimal or integer text matching the generator’s numeric pattern becomes an unquoted number; and lowercase `true` or `false` becomes the SQL literals `TRUE` or `FALSE`. Other cells are string literals. This is convenient when the CSV really represents those types and dangerous when a code, postcode or account number only looks numeric.

A string cell whose text is exactly `NULL` in any capitalization is emitted as the unquoted SQL `NULL`, even with type inference off and even if the CSV field was quoted. This special case happens in the SQL literal renderer after inference. There is no option to retain that exact word as text: use a reviewed manual edit or a parameterized import when it is legitimate data. Padded text such as ` NULL ` is not the same case and remains a quoted string.

With inference off, raw CSV fields stay strings, including blank fields. The SQL literal renderer then emits an empty field as `''`, not `NULL`; text `true` is quoted rather than becoming a boolean. The exact NULL-text exception still applies. Prefer this setting for identifiers and import data whose schema types you will explicitly validate later.

This generator has a different numeric rule from CSV to JSON. It accepts signed integers and decimals without leading zeros, but not exponent notation, leading plus signs or padded numbers. Lowercase true and false are recognized without trimming; uppercase TRUE is text. Leading-zero 007 remains a string, but 9007199254740993 matches the number rule and rounds to 9007199254740992 because there is no safe-integer guard. Extremely large matches can become non-finite and render as NULL. Disable inference for exact IDs or amounts and verify the quoted output.

String literals are escaped by doubling single quotes, the standard SQL convention: `O'Brien` becomes `'O''Brien'`. The output is intentionally text you can read and review; it is not an API for constructing queries at runtime. Runtime code should use the parameter binding facility provided by its database driver, even if this generated example looks correctly escaped.

The implementation does not add dialect-specific casts, binary literal forms, date constructors, encoding declarations or schema checks. It has no knowledge of triggers, generated columns, defaults, foreign keys or permissions. A statement that looks syntactically plausible can still fail or write the wrong kind of data when those database rules are applied.

MySQL is the important escaping caveat. The generated form relies on doubled single quotes. MySQL can also treat backslashes as escapes unless its `NO_BACKSLASH_ESCAPES` mode is enabled, so a backslash-containing value needs testing in the actual server mode. Do not assume a generated literal has identical backslash semantics across MySQL, PostgreSQL and SQL Server.

Generate a few rows first, preferably including every awkward value shape you expect. Compare the output column order with `DESCRIBE`, `\d`, migration source or another authoritative schema view. Confirm whether blanks are nulls, whether leading-zero values need inference disabled, and whether literal `NULL` should remain text.

Run the approved SQL in a disposable transaction or development database, then query the inserted rows back using the target database. This catches dialect behavior that static generation cannot know, including timestamp conversion, constraint failures and collation. Keep the original CSV and the reviewed generated SQL together so the operation is reproducible.

For large data, do not turn one statement per row into a deployment mechanism. The optional multi-row form is more compact, but servers impose statement, packet and transaction limits. Native facilities such as PostgreSQL COPY, MySQL LOAD DATA and SQL Server bulk tooling are designed for volume and offer better failure reporting.