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  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Список 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 по дате отправления:

Предыдущее
От: Michael Meskes
Дата:
Сообщение: Re: Thread-unsafe coding in ecpg
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Thread-unsafe coding in ecpg