Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Дата
Msg-id CAEYLb_V4awosaG+tf9GX2Sk5s84hPFPJBLABWAymiRpr4YZ5yw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 21 February 2012 01:48, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> you're proposing to move the error pointer to the "42", and that does
> not seem like an improvement, especially not if it only happens when the
> cast subject is a simple constant rather than an expression.

I'm not actually proposing that though. What I'm proposing, quite
simply, is that the Const location actually be correct in all
circumstances. Now, I can understand why the Coercion node for this
query would have its current location starting from the "CAST" part in
your second example or would happen to be the same as the Constant in
your first, and I'm not questioning that. I'm questioning why the
Const node's location need to *always* be the same as that of the
Coercion node when pg_stat_statements walks the tree, since I'd have
imagined that Postgres has no business blaming the error that you've
shown on the Const node.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services


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

Предыдущее
От: Marko Kreen
Дата:
Сообщение: Re: Speed dblink using alternate libpq tuple storage
Следующее
От: Noah Misch
Дата:
Сообщение: Re: 16-bit page checksums for 9.2