Re: Funny representation in pg_stat_statements.query. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Funny representation in pg_stat_statements.query.
Date
Msg-id 4499.1389973481@sss.pgh.pa.us
Whole thread Raw
In response to Funny representation in pg_stat_statements.query.  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: Funny representation in pg_stat_statements.query.  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List 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 by date:

Previous
From: Mel Gorman
Date:
Subject: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Next
From: Tom Lane
Date:
Subject: Re: Feature request: Logging SSL connections