Re: Cleaning up PREPARE query strings?
| От | Sami Imseih |
|---|---|
| Тема | Re: Cleaning up PREPARE query strings? |
| Дата | |
| Msg-id | CAA5RZ0uco6Xxsgo6p8FakgRJjY3PhnjePWWmZWxJO2Sz6Xf=CA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Cleaning up PREPARE query strings? (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
Hi, I think this is a good idea. > Julien Rouhaud <rjuju123@gmail.com> writes: > > I'm attaching a POC patch to fix that behavior by teaching PREPARE to clean the > > passed query text the same way as pg_stat_statements. > > This patch invalidates all the location fields in the parsed query: > they could not be used to generate sane error cursors referencing the > truncated string. I am not sure why we need to update the location of the rawstmt at all. CreateCachedPlan does not seem to care about location and length of query strings, AFAICT. ```rawstmt->stmt_location = 0;``` This is somewhat tangential, but I am now also wondering if CleanQuerytext itself should not mess with supplied statement location and length, but instead send back the location and length of the isolated query text within the multi-line query separately. From ``` extern const char *CleanQuerytext(const char *query, int *location, int *len); ``` To ``` extern const char *CleanQuerytext(const char *query, int location, int len, int *new_location, int *new_len); ``` It looks wrong that CleanQueryText is modifying any of the original locations and lengths. -- Sami Imseih Amazon Web Services (AWS)
В списке pgsql-hackers по дате отправления: