Kyotaro HORIGUCHI wrote:
Hello,
Since this becomes more than a simple bug fix, I think it is too
late for 9.4 now. I'll work on this in the longer term.
OK. I will get around to it someday, but if you do it first, that's fine.
Nevertheless of my words, the drive is getting
Hello, I found it would be reasonably fixed by small
modifications.
- CURRENT_TIME and the like are parsed into the nodes directly
represents the node specs in gram.y
blah, blah
Since this becomes more than a simple bug fix, I think it is too
late for 9.4 now. I'll work on this in the
Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp writes:
- CURRENT_TIME and the like are parsed into the nodes directly
represents the node specs in gram.y
blah, blah
Since this becomes more than a simple bug fix, I think it is too
late for 9.4 now. I'll work on this in the longer term.
OK.
On Tue, Jan 21, 2014 at 12:30 AM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
The fundamental cause of this issue is Const node which conveys
the location of other than constant tokens. Any other nodes, for
instance TypeCasts, are safe.
So this is fixed by quite simple way like
Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp writes:
The fundamental cause of this issue is Const node which conveys
the location of other than constant tokens. Any other nodes, for
instance TypeCasts, are safe.
So this is fixed by quite simple way like following getting rid
of the
Hi, considering on pg_stat_statements itself,
pg There was a more obvious case of this that I noticed during the
pg development of pg_stat_statements query normalization. As you may have
pg noticed, that was addressed by this commit:
pg
pg
Hello,
tgl So this is fixed by quite simple way like following getting rid
tgl of the referred difficulties of keeping the code sane and total
tgl loss of token locations. (white spaces are collapsed for readability)
tgl
tgl Committed with minor adjustments (improved comments, and hit one
tgl
On Tue, Jan 21, 2014 at 7:29 PM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
This apparently seems that the query passing through
pg_stat_statements twice during single execution. Actually, the
first one is a by-product of planning (simplify_function) and the
second is just what
Hello,
Since this becomes more than a simple bug fix, I think it is too
late for 9.4 now. I'll work on this in the longer term.
OK. I will get around to it someday, but if you do it first, that's fine.
Nevertheless of my words, the drive is getting diminished after
the issue was
Thank you.
tgl Hello, I noticed that pg_stat_statements.query can have funny values.
tgl
tgl I don't think that's an acceptable reason for lobotomizing the parser's
tgl ability to print error cursors, which is what your first patch does
tgl (and without even any documentation that would keep
Hello, I noticed that pg_stat_statements.query can have funny values.
| =# select pg_stat_statements_reset();
| =# select current_timestamp(0);
| snip
| =# select query from pg_stat_statements;
|query
|
| select ?(0);
| select
Kyotaro HORIGUCHI horiguchi.kyot...@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
12 matches
Mail list logo