Esiste uno standard SQL per eseguire l'escape di un nome di colonna? In caso contrario, cosa funziona per mysql e sqlite? funziona anche per sqlserver?
Esiste uno standard SQL per eseguire l'escape di un nome di colonna? In caso contrario, cosa funziona per mysql e sqlite? funziona anche per sqlserver?
Risposte:
"
Lo standard SQL: 1999 specifica che le virgolette doppie (") ( QUOTATION MARK ) vengono utilizzate per delimitare gli identificatori.
<delimited identifier> ::= <double quote> <delimited identifier body> <double quote>
Oracle, PostgreSQL, MySQL, MSSQL e SQlite supportano tutti "
come delimitatori di identificatori.
Non tutti usano "
come "impostazione predefinita". Ad esempio, devi eseguire MySQL in modalità ANSI e SQL Server lo supporta solo quando lo QUOTED_IDENTIFIER
è ON
.
Secondo SQLite ,
'foo'
è una stringa SQL"foo"
è un identificatore SQL (colonna / tabella / ecc.)[foo]
è un identificatore in MS SQL`foo`
è un identificatore in MySQLPer i nomi qualificati, la sintassi è: "t"."foo"
o [t].[foo]
, ecc.
MySQL supporta lo standard "foo" quando l' ANSI_QUOTES
opzione è abilitata.
WHERE "nonexistent_column" = 0
e sqlite lo ha eseguito felicemente fingendo che la mia "nonexistent_column"
fosse una stringa. Qualificare completamente il nome come "my_table"."nonexistent_column"
obbliga sqlite a comportarsi in modo più rigoroso.
foo
, "foo"
E 'foo'
non ha funzionato per me con MySQL. Richiedeva backtick. E come se non bastasse, MySQL forniva messaggi di errore inutili .
Per MySQL, usa i tick indietro `.
Per esempio:
SELECT `column`, `column2` FROM `table`
Per MS SQL utilizzare [e]
SELECT [COLUMN], [COLUMN 2] FROM [TABLE]
Per DBASE / DBF utilizzare [
e]
SELECT [DATE], [TIME], [ANY_OTHER_TO_BE_ESCAPED_COLUMN] FROM [TABLE]
Mettendo insieme alcune risposte:
MS SQL (noto anche come T-SQL), Microsoft Access SQL, DBASE / DBF: SELECT [COLUMN], [COLUMN2] FROM [TABLE]
MySQL: SELECT `COLUMN`, `COLUMN2` FROM `TABLE`
SQLite, Oracle, Postgresql: SELECT "COLUMN", "COLUMN2" FROM "TABLE"
Si prega di aggiungere / modificare!
'foo'
di essere interpretato come un identificatore se il contesto non consente una stringa e"foo"
di essere interpretato come una stringa se il contesto non consente un identificatore, anche se c'è una nota che questo comportamento potrebbe essere rimosso in futuro versioni.