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
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 s
On Tue, Jan 21, 2014 at 7:29 PM, Kyotaro HORIGUCHI
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 expected by users. It surely
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
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>
http://git.postgresql.org/gitweb/?p=postgresql.git;
Kyotaro HORIGUCHI 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 referred difficulties of keepin
On Tue, Jan 21, 2014 at 12:30 AM, Kyotaro HORIGUCHI
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 following getting rid
> of t
Kyotaro HORIGUCHI writes:
>> - CURRENT_TIME and the like are parsed into the nodes directly
>> represents the node specs in gram.y
>>
>> 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 someda
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
> 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 ter
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 ke
Kyotaro HORIGUCHI 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
11 matches
Mail list logo