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 | 8047.1330710510@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation) (Josh Berkus <josh@agliodbs.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) Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation) |
Список | pgsql-hackers |
Josh Berkus <josh@agliodbs.com> writes: >> It would probably be prudent to concentrate on getting the core >> infrastructure committed first. That way, we at least know that if >> this doesn't get into 9.2, we can work on getting it into 9.3 knowing >> that once committed, people won't have to wait over a year at the very > I don't see why we can't commit the whole thing. This is way more ready > for prime-time than checksums. We'll get to it in due time. In case you haven't noticed, there's a lot of stuff in this commitfest. And I don't follow the logic that says that because Simon is trying to push through a not-ready-for-commit patch we should drop our standards for other patches. regards, tom lane
В списке pgsql-hackers по дате отправления: