Re: Improve handling of pg_stat_statements handling of bind "IN" variables
От | Pavel Trukhanov |
---|---|
Тема | Re: Improve handling of pg_stat_statements handling of bind "IN" variables |
Дата | |
Msg-id | CAF42k=LHMr-ig4ydjr6V1_MKAN58VprSmf=d1UdzZp56HH_J5Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Improve handling of pg_stat_statements handling of bind "IN" variables (Dmitry Dolgov <9erthalion6@gmail.com>) |
Ответы |
Re: Improve handling of pg_stat_statements handling of bind "IN" variables
|
Список | pgsql-hackers |
Thanks for your reply > If I understand correctly, "IN (...)" is reprecented by A_Expr with kind > AEXPR_IN, and only in transformAExprIn converted to ArrayExpr if possible. That seems to be correct, yes, thank you. > So probably it doesn't makes sense to introduce another one. Though I might've used wrong words to describe my holdback here, what I meant is that I'll need to create new node type (in primnodes.h?) for IN-list, that will allow to differentiate it from direct "ARRAY" usage. This will require changes to parse_expr.c, execExpr.c, etc, which seems to be overkill for such issue IMO, hence the question. Please advise. > > For example "SELECT ARRAY[1, 2, a] FROM table" and "SELECT ARRAY[b] > > FROM table" might end up in the same pgss entry. > > What are a, b here, parameters? Here a and b are table columns. I couldn't come up with other examples of ARRAY usage, would appreciate any suggestions. > > 3 Tests in pgss.sql/out and Vars > > I would like someone to point me in a direction of how could I > > implement a test that will query > > "SELECT * FROM test WHERE a IN ($1, $2, $3, ...)" with params, not > > consts > > Wouldn't a prepared statement work? It will create an ArrayExpr with Params > inside. Thanks for the tip. It seems to work, at least it looks like it.
В списке pgsql-hackers по дате отправления: