Re: Query Jumbling for CALL and SET utility statements
Вложения
В списке pgsql-hackers по дате отправления:
| От | Michael Paquier |
|---|---|
| Тема | Re: Query Jumbling for CALL and SET utility statements |
| Дата | |
| Msg-id | Yz+nUUVc3UtJtU6q@paquier.xyz обсуждение |
| Ответ на | Re: Query Jumbling for CALL and SET utility statements (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Query Jumbling for CALL and SET utility statements
|
| Список | pgsql-hackers |
On Thu, Oct 06, 2022 at 11:51:52PM -0400, Tom Lane wrote: > I've been thinking since the beginning of this thread that there > was no coherent, defensible rationale being offered for jumbling > some utility statements and not others. Yeah. The potential performance impact of all the TransactionStmts worries me a bit, though. > I wonder if the answer is to jumble them all. We avoided that > up to now because it would imply a ton of manual effort and > future code maintenance ... but now that the backend/nodes/ > infrastructure is largely auto-generated, could we auto-generate > the jumbling code? Probably. One part that may be tricky though is the location of the constants we'd like to make generic, but perhaps this could be handled by using a dedicated variable type that just maps to int? It does not seem like a mandatory requirement to add that everywhere as a first step, either. -- Michael
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера