Text on BareSQL.com

A Backslash in LIKE Escapes Percent and Underscore Everywhere Except SQLite

Mon, 26 Oct 2026 00:00:00 +0000

Searching for the text 50_off with LIKE '50\_off' works on PostgreSQL, MySQL and MariaDB, where the backslash escapes the underscore. SQLite treats the backslash as an ordinary character, and the search finds nothing.

'a_b' LIKE 'a\_b' is true on PostgreSQL, MySQL and MariaDB, where \_ matches an underscore, and false on SQLite, where the pattern asks for a backslash followed by any one character.

A Backslash Is an Escape Character in MySQL Strings and a Plain Character in PostgreSQL

Mon, 26 Oct 2026 00:00:00 +0000

A Windows path written as 'C:\temp\new' reads back on MySQL and MariaDB with a tab and a line break in it. PostgreSQL and SQLite keep the backslashes as typed.

'C:\\temp' is C:\\temp, two backslashes, on SQLite and PostgreSQL and C:\temp on MySQL and MariaDB. '\t' is a tab and '\'' a quote there, while PostgreSQL needs its E'...' strings for escapes, which no other engine reads. MySQL’s NO_BACKSLASH_ESCAPES mode makes it read backslashes like the others.

CAST to CHAR Cuts a Value to One Character on PostgreSQL

Mon, 26 Oct 2026 00:00:00 +0000

CAST(order_id AS CHAR) looks like a safe way to turn a number into text. On PostgreSQL CHAR without a length means one character, so order 123 comes back as '1'.

PostgreSQL reads CHAR without a length as CHAR(1) and cuts the value to fit. With a length, CHAR(10), it pads the value with spaces. MySQL accepts CHAR in CAST but neither VARCHAR nor TEXT, and MariaDB accepts VARCHAR but not TEXT.

CHAR Columns Come Back Padded With Spaces on PostgreSQL

Mon, 26 Oct 2026 00:00:00 +0000

An order status kept in a CHAR(10) column compares as expected in SQL on every engine. In the application code, though, a check for paid orders fails on PostgreSQL alone.

A CHAR(5) column holding 'a' returns 'a ' on PostgreSQL. Comparisons there ignore the padding, so WHERE c = 'a' still matches, but the spaces reach the application and CONCAT. MySQL and MariaDB strip trailing spaces when they read CHAR values, and SQLite does not apply the length at all.

Comparing a Text Column With the Number 0 Matches Codes Like abc on MySQL and Fails on PostgreSQL

Mon, 26 Oct 2026 00:00:00 +0000

Product codes are text, and a query that forgets the quotes, WHERE code = 0, still runs on MySQL and MariaDB. There it returns codes that have nothing to do with 0.

MySQL and MariaDB turn the text into a number, and text that does not start with digits becomes 0, so WHERE code = 0 finds every code like 'abc'. SQLite compares the number as text and finds nothing. PostgreSQL refuses to compare character varying with integer. '1' = 1 trips over the same thing in another way: false on SQLite, true on the other three.

CONCAT With a NULL Argument Returns NULL on MySQL and Skips It on PostgreSQL

Mon, 26 Oct 2026 00:00:00 +0000

A customer list built with CONCAT(first_name, ' ', last_name) looks complete on PostgreSQL and SQLite. Moved to MySQL or MariaDB, the same query returns NULL for some customers.

A person without a last name comes out as 'Ann ' on SQLite and PostgreSQL and as NULL on MySQL and MariaDB, so a list of names quietly loses entries there. CONCAT_WS skips NULL arguments on all four engines.

LENGTH Counts Bytes on MySQL and MariaDB and Characters on PostgreSQL and SQLite

Mon, 26 Oct 2026 00:00:00 +0000

A check that a name is at most 20 characters long, written with LENGTH(name), lets 20 letters through on SQLite and PostgreSQL. MySQL and MariaDB count bytes instead, so a name with accents reaches the limit sooner.

In UTF-8 a letter outside A to Z takes two to four bytes. MySQL and MariaDB count characters with CHAR_LENGTH, which SQLite lacks. Length checks and cut-offs drift apart on names and addresses with accents.

LIKE Ignores Letter Case on SQLite and MySQL and Respects It on PostgreSQL

Mon, 26 Oct 2026 00:00:00 +0000

A search box that runs WHERE name LIKE 'ann%' finds Ann on SQLite, MySQL and MariaDB. On PostgreSQL it misses her, because LIKE there compares letters exactly.

SQLite’s LIKE ignores case for the letters A to Z only. MySQL and MariaDB follow the collation, which ignores case by default. PostgreSQL’s LIKE is exact; its ILIKE ignores case, and exists on PostgreSQL only.

MySQL Compares Text Without Regard to Letter Case and PostgreSQL Compares It Exactly

Mon, 26 Oct 2026 00:00:00 +0000

Sign-ups as ann@example.com and Ann@example.com are two users on PostgreSQL and SQLite. On MySQL and MariaDB a unique key on the email column refuses the second sign-up.

The default collations of MySQL and MariaDB ignore case and accents, so 'abc' = 'ABC' and 'e' = 'é' are true there and false on SQLite and PostgreSQL. The same goes for joins, GROUP BY, DISTINCT and unique keys: two values that differ only in case count as one on MySQL and as two elsewhere. Whether an answer changes depends on the data, so lint reports this as information.

SQLite LOWER and UPPER Change Only the Letters A to Z

Mon, 26 Oct 2026 00:00:00 +0000

Searching names with LOWER(name) = LOWER('Émile') works on PostgreSQL, MySQL and MariaDB. On SQLite, LOWER changes only A to Z, so É stays É and a stored émile never matches.

SQLite folds case for ASCII letters only, and so do its LIKE and COLLATE NOCASE, unless it is built with the ICU extension, as some systems ship it. Comparisons that use LOWER() to ignore case work on the other engines and fail on SQLite for names like Émile or Ødegaard.

SUBSTR From Position 0 Returns Text on SQLite and PostgreSQL and Nothing on MySQL

Mon, 26 Oct 2026 00:00:00 +0000

Code ported from a language that counts from 0 often ends up with SUBSTR(code, 0, 3). SQLite and PostgreSQL return the first two characters. MySQL and MariaDB return an empty string.

Positions start at 1. SQLite and PostgreSQL count position 0 as part of the requested length, while MySQL and MariaDB return nothing for a start of 0. Negative starts differ as well: SQLite, MySQL and MariaDB count them from the end, and PostgreSQL counts them before the first character.

The Double Pipe Operator Joins Text on PostgreSQL and SQLite and Means OR on MySQL

Mon, 26 Oct 2026 00:00:00 +0000

Code that builds labels with first_name || ' ' || last_name works on PostgreSQL and SQLite. Move it to MySQL or MariaDB and every label comes back as 0, with no error to say why.

The SQL standard joins strings with ||, and SQLite and PostgreSQL follow it. MySQL and MariaDB read || as a logical OR unless the server runs in the PIPES_AS_CONCAT mode, so both strings are turned into numbers and the answer is 0. The warnings they give for it seldom reach the application.