Итак, в моем Postgresql есть:
TAG_TABLE
==========================
id tag_name
--------------------------
1 aaa
2 bbb
3 ccc
Чтобы упростить мою проблему, я хочу выбрать «id» из TAG_TABLE, когда строка «aaaaaaaa» содержит «tag_name». Поэтому в идеале он должен возвращать только "1", который является идентификатором имени тега 'aaa'.
Вот чем я пока занимаюсь:
SELECT id FROM TAG_TABLE WHERE 'aaaaaaaaaaa' LIKE '%tag_name%'
Но очевидно, что это не работает, поскольку postgres считает, что «% tag_name%» означает шаблон, содержащий подстроку «tag_name» вместо фактического значения данных в этом столбце.
Как передать tag_name в шаблон ??
sql
postgresql
user2436815
источник
источник
"; drop table TAG_TABLE; --"
?WHERE
предложение оценивается какFALSE
. Оператор не является динамическим, объединяются только значения, нет возможности для SQL-инъекции.LIKE
ключевого слова.LIKE
шаблоне может иметь непредвиденные последствия, если эти переменные содержат символы подчеркивания (_) или символы процента (%). Может потребоваться экранировать эти символы, например, с помощью этой функции:CREATE OR REPLACE FUNCTION quote_for_like(text) RETURNS text LANGUAGE SQL IMMUTABLE AS $$ SELECT regexp_replace($1, '([\%_])', '\\\1', 'g'); $$;
(от пользователя MatheusOl из IRC-канала #postgresql на Freenode).Лично я предпочитаю более простой синтаксис оператора ~.
Стоит прочитать Разница между LIKE и ~ в Postgres, чтобы понять разницу. `
источник
tag_name
правильном REGEX. Довольно рискованно.***=
которое упоминается в postgresql.org/docs/current/static/functions-matching.html . Однако я обнаружил, что это намного медленнее по сравнению сstrpos
/position
solutions.Правильный путь для поиска подстроки является использование
position
функции вместоlike
выражения, которое требует побега%
,_
и экранирующего символ (\
по умолчанию):источник
LIKE
иILIKE
может использоватьgin
индексы.position
не может.В дополнение к решению с
'aaaaaaaa' LIKE '%' || tag_name || '%'
существуютposition
(обратный порядок аргументов) иstrpos
.Помимо того, что более эффективно (LIKE выглядит менее эффективным, но индекс может изменить ситуацию), с LIKE есть очень небольшая проблема: tag_name, конечно, не должен содержать,
%
и особенно_
(одиночный символ подстановки), чтобы не давать ложных срабатываний.источник
tag_name
должен быть в цитате, иначе будет выдана ошибка, так как tag_name не существуетисточник