Re: pg_stat_statements vs. SELECT FOR UPDATE
От | Tom Lane |
---|---|
Тема | Re: pg_stat_statements vs. SELECT FOR UPDATE |
Дата | |
Msg-id | 23804.1547944318@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_stat_statements vs. SELECT FOR UPDATE (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Ответы |
Re: pg_stat_statements vs. SELECT FOR UPDATE
|
Список | pgsql-hackers |
Andrew Gierth <andrew@tao11.riddles.org.uk> writes: > "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: > Tom> +1 for not ignoring rowMarks, but this patch seems like a hack to > Tom> me. Why didn't you just add RowMarkClause as one of the known > Tom> alternative expression node types? > Because it's not an expression and nothing anywhere else in the backend > treats it as such? Places such as outfuncs.c and copyfuncs.c don't draw a distinction, and I don't see why pg_stat_statements should either. It would just be one more place we'd have to fix if we ever allow RowMarkClause in other places --- or, perhaps more realistically, if the structure of Query.rowMarks becomes more complex than "flat list of RowMarkClauses". The other places you mention generally have some specific semantic knowledge about rowmarks, and would have to be touched anyway if any changes like that happen. But the jumbling code in pg_stat_statements has no knowledge of any of that, it's just interested in traversing the tree. So I'd put it on the same semantic level as outfuncs.c. regards, tom lane
В списке pgsql-hackers по дате отправления: