Rest
...parameters: unknown[]This can be used to add arbitrary identifiers to SQL snippets.
Does the same thing as ref and table but can also be used for any other identifiers like index names.
You should use ref and table instead of this whenever possible as they produce a more sematic operation node tree.
WARNING! Using this with unchecked inputs WILL lead to SQL injection vulnerabilities. The input is not checked or escaped by Kysely in any way.
const indexName = 'person_first_name_index'
sql`create index ${indexName} on person`
The generated SQL (PostgreSQL):
create index "person_first_name_index" on person
Multiple identifiers get separated by dots:
const schema = 'public'
const columnName = 'first_name'
const table = 'person'
sql`select ${sql.id(schema, table, columnName)}} from ${sql.id(schema, table)}`
The generated SQL (PostgreSQL):
select "public"."person"."first_name" from "public"."person"
Rest
...ids: readonly string[]This can be used to add lists of things to SQL snippets.
function findByNicknames(nicknames: string[]): Promise<Person[]> {
return db
.selectFrom('person')
.selectAll()
.where('nicknames', '@>', sql`ARRAY[${sql.join(nicknames)}]`)
.execute()
}
The generated SQL (PostgreSQL):
select * from "person"
where "nicknames" @> ARRAY[$1, $2, $3, $4, $5, $6, $7, $8]
The second argument is the joining SQL expression that defaults to
sql`, `
In addition to values, items in the list can be also sql expressions, queries or anything else the normal substitutions support:
const things = [
123,
sql`(1 == 1)`,
db.selectFrom('person').selectAll(),
sql.lit(false),
sql.id('first_name')
]
sql`BEFORE ${sql.join(things, sql`::varchar, `)} AFTER`
The generated SQL (PostgreSQL):
BEFORE $1::varchar, (1 == 1)::varchar, (select * from "person")::varchar, false::varchar, "first_name" AFTER
Optional
separator: RawBuilder<any>This can be used to add literal values to SQL snippets.
WARNING! Using this with unchecked inputs WILL lead to SQL injection vulnerabilities. The input is not checked or escaped by Kysely in any way. You almost always want to use normal substitutions that get sent to the db as parameters.
const firstName = 'first_name'
sql`select * from person where first_name = ${sql.lit(firstName)}`
The generated SQL (PostgreSQL):
select * from person where first_name = 'first_name'
As you can see from the example above, the value was added directly to the SQL string instead of as a parameter. Only use this function when something can't be sent as a parameter.
Use lit instead.
This can be used to add arbitrary runtime SQL to SQL snippets.
WARNING! Using this with unchecked inputs WILL lead to SQL injection vulnerabilities. The input is not checked or escaped by Kysely in any way.
const firstName = "'first_name'"
sql`select * from person where first_name = ${sql.raw(firstName)}`
The generated SQL (PostgreSQL):
select * from person where first_name = 'first_name'
Note that the difference to sql.lit
is that this function
doesn't assume the inputs are values. The input to this function
can be any sql and it's simply glued to the parent string as-is.
This can be used to add runtime column references to SQL snippets.
By default ${}
substitutions in sql template strings get
transformed into parameters. You can use this function to tell
Kysely to interpret them as column references instead.
WARNING! Using this with unchecked inputs WILL lead to SQL injection vulnerabilities. The input is not checked or escaped by Kysely in any way.
const columnRef = 'first_name'
sql`select ${sql.ref(columnRef)} from person`
The generated SQL (PostgreSQL):
select "first_name" from person
The refefences can also include a table name:
const columnRef = 'person.first_name'
sql`select ${sql.ref(columnRef)}} from person`
The generated SQL (PostgreSQL):
select "person"."first_name" from person
The refefences can also include a schema on supported databases:
const columnRef = 'public.person.first_name'
sql`select ${sql.ref(columnRef)}} from person`
The generated SQL (PostgreSQL):
select "public"."person"."first_name" from person
This can be used to add runtime table references to SQL snippets.
By default ${}
substitutions in sql template strings get
transformed into parameters. You can use this function to tell
Kysely to interpret them as table references instead.
WARNING! Using this with unchecked inputs WILL lead to SQL injection vulnerabilities. The input is not checked or escaped by Kysely in any way.
const table = 'person'
sql`select first_name from ${sql.table(table)}`
The generated SQL (PostgreSQL):
select first_name from "person"
The refefences can also include a schema on supported databases:
const table = 'public.person'
sql`select first_name from ${sql.table(table)}`
The generated SQL (PostgreSQL):
select first_name from "public"."person"
sql.val(value)
is a shortcut for:
sql<ValueType>`${value}`
Use val instead.
Generated using TypeDoc
Template tag for creating raw SQL snippets and queries.
Substitutions (the things inside
${}
) are automatically passed to the database as parameters and are never interpolated to the SQL string. There's no need to worry about SQL injection vulnerabilities. Substitutions can be values, othersql
expressions, queries and almost anything else Kysely can produce and they get handled correctly. See the examples below.If you need your substitutions to be interpreted as identifiers, value literals or lists of things, see the ref, table, id, lit, raw and join functions.
You can pass sql snippets returned by the
sql
tag pretty much anywhere. Whenever something can't be done using the Kysely API, you should be able to drop down to raw SQL using thesql
tag. Here's an example query that uses raw sql in a bunch of methods:The generated SQL (PostgreSQL):
SQL snippets can be executed by calling the
execute
method and passing aKysely
instance as the only argument:You can merge other
sql
expressions and queries using substitutions:Substitutions also handle ref, ref and pretty much anything else you throw at it. Here's an example of calling a function in a type-safe way:
don't know if that amount of ceremony is worth the small increase in type-safety though... But it's possible.