Re: Funny representation in pg_stat_statements.query.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Funny representation in pg_stat_statements.query.
Дата
Msg-id 4499.1389973481@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Funny representation in pg_stat_statements.query.  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Ответы Re: Funny representation in pg_stat_statements.query.  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список pgsql-hackers
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes:
> Hello, I noticed that pg_stat_statements.query can have funny values.

I don't think that's an acceptable reason for lobotomizing the parser's
ability to print error cursors, which is what your first patch does
(and without even any documentation that would keep someone from
changing it back).

The second patch might be all right, though I'm a bit disturbed by its
dependency on gram.h constants.  The numeric values of those change on a
regular basis, and who's to say that these are exactly the set of tokens
that we care about?

In the end, really the cleanest fix for this would be to get rid of the
grammar's translation of these special functions into hacky expressions.
They ought to get translated into some new node type(s) that could be
reverse-listed in standard form by ruleutils.c.  I've wanted to do that
for years, but never got around to it ...
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Mel Gorman
Дата:
Сообщение: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Feature request: Logging SSL connections