Re: pg_stat_statements and "IN" conditions
От | Tom Lane |
---|---|
Тема | Re: pg_stat_statements and "IN" conditions |
Дата | |
Msg-id | 178940.1647271397@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_stat_statements and "IN" conditions (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: pg_stat_statements and "IN" conditions
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, Mar 14, 2022 at 10:57 AM Dmitry Dolgov <9erthalion6@gmail.com> wrote: >> I'm not sure if I follow the last point. WHERE x in (1,3) and x = >> any(array[1,3]) are two different things for sure, but in which way are >> they going to be mixed together because of this change? My goal was to >> make only the following transformation, without leaving any uncertainty: >> >> WHERE x in (1, 2, 3, 4, 5) -> WHERE x in (1, 2, ...) >> WHERE x = any(array[1, 2, 3, 4, 5]) -> WHERE x = any(array[1, 2, ...]) > I understand. I think it might be OK to transform both of those > things, but I don't think it's very clear either from the comments or > the nonexistent documentation that both of those cases are affected -- > and I think that needs to be clear. We've transformed IN(...) to ANY(ARRAY[...]) at the parser stage for a long time, and this has been visible to users of either EXPLAIN or pg_stat_statements for the same length of time. I doubt people are going to find that surprising. Even if they do, it's not the query jumbler's fault. I do find it odd that the proposed patch doesn't cause the *entire* list to be skipped over. That seems like extra complexity and confusion to no benefit. regards, tom lane
В списке pgsql-hackers по дате отправления: