Решил на днях поставить wordpress + pgsql, как известно расширение PG4WP с текущей версией WP ( 3.8.1 ) не работает, решил его доработать, расширение само по себе представляет парсер запросов mysql в pgsql, первый же запрос выглядит как
1.
2.
3.
4.
5.
DELETE a, b FROM pgwp_options a, pgwp_options b
WHERE a.option_name LIKE '\_transient\_%'
AND a.option_name NOT LIKE '\_transient\_timeout\_%'
AND b.option_name = CONCAT( '_transient_timeout_', SUBSTRING( a.option_name, 12 ) )
AND b.option_value <= 1396370722
при этом поле
option_value типа varchar.
написал парсер такого запроса в вид, который вроде как должен работать в postgree:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
delete
from pgwp_options
where option_id in (
select option_id
from ( select a.option_id
, b.option_value
from pgwp_options a, pgwp_options b
WHERE a.option_name LIKE '\_transient\_%'
AND a.option_name NOT LIKE '\_transient\_timeout\_%'
AND b.option_name = CONCAT( '_transient_timeout_', SUBSTRING( a.option_name, 12 ) )
union
select b.option_id
, b.option_value
from pgwp_options a
, pgwp_options b
WHERE a.option_name LIKE '\_transient\_%'
AND a.option_name NOT LIKE '\_transient\_timeout\_%'
AND b.option_name = CONCAT( '_transient_timeout_', SUBSTRING( a.option_name, 12 ) )
) t1 where cast ( t1.option_value as numeric ) <= 1396370722 )
но он не работает, ругается на то что
t1.option_value не является числовым, хотя внутренний обзединённый запрос по отдельности выводит только те строки в которых
option_value состоит только из цифр.
Вероятно где то в процессе подготовки запроса, оптимизатор решает, что быстрее сначала проверить условие
cast ( t1.option_value as numeric ) <= 1396370722 )
при этом если изменить запрос до вида:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
select option_id
from ( select a.option_id
, cast ( b.option_value as numeric ) as option_value
from pgwp_options a, pgwp_options b
WHERE a.option_name LIKE '\_transient\_%'
AND a.option_name NOT LIKE '\_transient\_timeout\_%'
AND b.option_name = CONCAT( '_transient_timeout_', SUBSTRING( a.option_name, 12 ) )
union
select b.option_id
, cast ( b.option_value as numeric ) as option_value
from pgwp_options a
, pgwp_options b
WHERE a.option_name LIKE '\_transient\_%'
AND a.option_name NOT LIKE '\_transient\_timeout\_%'
AND b.option_name = CONCAT( '_transient_timeout_', SUBSTRING( a.option_name, 12 ) )
) t1 where t1.option_value as numeric <= 1396370722
ситуация не меняется, т.е. запрос
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
elect a.option_id
, cast ( b.option_value as numeric ) as option_value
from pgwp_options a, pgwp_options b
WHERE a.option_name LIKE '\_transient\_%'
AND a.option_name NOT LIKE '\_transient\_timeout\_%'
AND b.option_name = CONCAT( '_transient_timeout_', SUBSTRING( a.option_name, 12 ) )
union
select b.option_id
, cast ( b.option_value as numeric ) as option_value
from pgwp_options a
, pgwp_options b
WHERE a.option_name LIKE '\_transient\_%'
AND a.option_name NOT LIKE '\_transient\_timeout\_%'
AND b.option_name = CONCAT( '_transient_timeout_', SUBSTRING( a.option_name, 12 ) )
отрабатывает без проблем возвращая только числовые значения, а в сумме не работает.
проблему причём можно решить ( правда при таком поведении неизвестно насколько верно ) изменив условие внешнего запроса на
1.
where t1.option_value similar to '[[:digit:]]' and cast ( t1.option_value as numeric ) <= 1396370722 )
в первом запросе.
к сожалению создать простой скрипт для сравнения не удалось, т.к. на простых таблицах оптимизатор преобразование сдвигает на последнюю стадию, и ошибка не вылетает ( сама ошибка - неверный синтаксис для типа numeric "строка с буквами которой в рез подзапроса быть не должно" )
в результате данных изысканий задался вопросом, правильно ли работает оптимизатор, и соответственно стоит ли постить как баг.
p.s. как решить задачу с запросом в принципе я нашёл ( 2 способа, собств. функция или pgsql блок ) интересует именно правильно ли с точки зрения теории и документации работает postgree.
