Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
От | Tom Lane |
---|---|
Тема | Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation) |
Дата | |
Msg-id | 24810.1332876415@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: 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)
Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation) |
Список | pgsql-hackers |
Peter Geoghegan <peter@2ndquadrant.com> writes: > I've attached a patch with the required modifications. I've committed the core-backend parts of this, just to get them out of the way. Have yet to look at the pg_stat_statements code itself. > I restored the location field to the ParamCoerceHook signature, but > the removal of code to modify the param location remains (again, not > because I need it, but because I happen to think that it ought to be > consistent with Const). I ended up choosing not to apply that bit. I remain of the opinion that this behavior is fundamentally inconsistent with the general rules for assigning parse locations to analyzed constructs, and I see no reason to propagate that inconsistency further than we absolutely have to. regards, tom lane
В списке pgsql-hackers по дате отправления: