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

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Дата
Msg-id CAEYLb_WeGtUozjbyB8rZM8nZzidvFLZVfFJE9VDwZUpT9a6XEQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)  (Peter Geoghegan <peter@2ndquadrant.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 20 February 2012 23:16, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> Clearly this change is a quick and dirty workaround, and something
> better is required. The question I'd pose to the maintainer of this
> code is: what business does the coerce_to_target_type call have
> changing the location of the Const node resulting from coercion under
> the circumstances described? I understand that the location of the
> CoerceToDomain should be at "CAST", but why should the underlying
> Const's position be the same?

Another look around shows that the CoerceToDomain struct takes its
location from the new Const location in turn, so my dirty little hack
will break the location of the CoerceToDomain struct, giving an
arguably incorrect caret position in some error messages. It would
suit me if MyCoerceToDomain->arg (or the "arg" of a similar node
related to coercion, like CoerceViaIO) pointed to a Const node with,
potentially, and certainly in the case of my original CoerceToDomain
test case, a distinct location to the coercion node itself.

Can we do that?

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


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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: 16-bit page checksums for 9.2
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)