Transforming IN (...) to ORs, volatility

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Transforming IN (...) to ORs, volatility
Дата
Msg-id 4D95B605.2020709@enterprisedb.com
обсуждение исходный текст
Ответы Re: Transforming IN (...) to ORs, volatility  (Gianni Ciolli <gianni.ciolli@2ndquadrant.it>)
Re: Transforming IN (...) to ORs, volatility  (Robert Haas <robertmhaas@gmail.com>)
Re: Transforming IN (...) to ORs, volatility  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Transforming IN (...) to ORs, volatility  (Marti Raudsepp <marti@juffo.org>)
Список pgsql-hackers
We sometimes transform IN-clauses to a list of ORs:

postgres=# explain SELECT * FROM foo WHERE a IN (b, c);                      QUERY PLAN
------------------------------------------------------ Seq Scan on foo  (cost=0.00..39.10 rows=19 width=12)   Filter:
((a= b) OR (a = c))
 
(2 rows)

But what if you replace "a" with a volatile function? It doesn't seem 
legal to do that transformation in that case, but we do it:

postgres=# explain SELECT * FROM foo WHERE (random()*2)::integer IN (b, c);
       QUERY PLAN 
 


-------------------------------------------------------------------------------------------------
------------------- Seq Scan on foo  (cost=0.00..68.20 rows=19 width=12)   Filter: ((((random() * 2::double
precision))::integer= b) OR 
 
(((random() * 2::double precision))::integer = c))
(2 rows)

I tried to read the SQL spec to see if it has anything to say about 
that, but I couldn't find anything. My common sense says that that 
transformation is not legal.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Gianni Ciolli
Дата:
Сообщение: Re: maximum digits for NUMERIC
Следующее
От: Noah Misch
Дата:
Сообщение: Re: maximum digits for NUMERIC