Thread: Ticket 186: Reseting a table/function's statistics
Hi, Now that I'm done translating the 9.0 PostgreSQL manual, I get back to pgAdmin's coding. I know we didn't deliver yet 1.12, but I can start the work on my git branches. So, this patch adds a new contextual menu to individual table and function. This menu allows one to reset this specific table (or function) statistics. Comments? PS: of course, I won't commit until we branch out 1.12. -- Guillaume http://www.postgresql.fr http://dalibo.com
Attachment
On Fri, Jun 18, 2010 at 4:54 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Hi, > > Now that I'm done translating the 9.0 PostgreSQL manual, I get back to > pgAdmin's coding. I know we didn't deliver yet 1.12, but I can start the > work on my git branches. > > So, this patch adds a new contextual menu to individual table and > function. This menu allows one to reset this specific table (or > function) statistics. > > Comments? Cool. > PS: of course, I won't commit until we branch out 1.12. I think I've given up on my desire to have a sequential commit reference for QA's benefit. We should figure out how we can move to GIT withut breaking the back branches which currently still use that. Doing so would make this sort of work easier.... -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company
Le 18/06/2010 22:59, Dave Page a écrit : > On Fri, Jun 18, 2010 at 4:54 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: > [...] >> PS: of course, I won't commit until we branch out 1.12. > > I think I've given up on my desire to have a sequential commit > reference for QA's benefit. We should figure out how we can move to > GIT withut breaking the back branches which currently still use that. > I don't get it. What are you afraid of breaking? the sequential commit reference will break for everything, back branches and trunk. > Doing so would make this sort of work easier.... > As a matter of fact, it'll make it easier. But it's already not that hard. I just keep it in a separate branch, and merging is really easy with git. Moreover, I don't intend to work on a lot of patches till we branch. This one was just a warm-up. I'll now work on a better i18n. And then, exclusion constraint and SQL/Med objects. Which would already be great to have in mid-august. -- Guillaume http://www.postgresql.fr http://dalibo.com
On Fri, Jun 18, 2010 at 5:55 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le 18/06/2010 22:59, Dave Page a écrit : >> On Fri, Jun 18, 2010 at 4:54 PM, Guillaume Lelarge >> <guillaume@lelarge.info> wrote: >> [...] >>> PS: of course, I won't commit until we branch out 1.12. >> >> I think I've given up on my desire to have a sequential commit >> reference for QA's benefit. We should figure out how we can move to >> GIT withut breaking the back branches which currently still use that. >> > > I don't get it. What are you afraid of breaking? the sequential commit > reference will break for everything, back branches and trunk. The current code expects to be in an SVN repo, and runs things like 'svn info' at build time. >> Doing so would make this sort of work easier.... > > As a matter of fact, it'll make it easier. But it's already not that > hard. I just keep it in a separate branch, and merging is really easy > with git. Moreover, I don't intend to work on a lot of patches till we > branch. This one was just a warm-up. I'll now work on a better i18n. And > then, exclusion constraint and SQL/Med objects. Which would already be > great to have in mid-august. :-) -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company