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_XjHontuTdkgkbMC+E55PXkT4-Oi1yf_rdSeuF1SHsi2Q@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>) |
| Ответы |
Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
|
| Список | pgsql-hackers |
On 27 March 2012 18:15, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I am thinking that perhaps a reasonable signature for the hook function > would be > > void post_parse_analyze (ParseState *pstate, Query *query); > > with the expectation that it could dig whatever it wants to know out > of the ParseState (in particular the sourceText is available there, > and in general this should provide everything that's known at parse > time). It seems reasonable to suggest that this will provide everything known at parse time. > Now, if what it wants to know about is the parameterization status > of the query, things aren't ideal because most of the info is hidden > in parse-callback fields that aren't of globally exposed types. However > we could at least duplicate the behavior you have here, because you're > only passing canonicalize = true in cases where no parse callback will > be registered at all, so pg_stat_statements could equivalently test for > pstate->p_paramref_hook == NULL. It has been suggested to me before that comparisons with function pointers - using them as a flag, in effect - is generally iffy, but that particular usage seems reasonable to me. Attached is a revision with the suggested changes. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
Вложения
В списке pgsql-hackers по дате отправления: