Thread: pgadmin3: present and future
***Functionality right now: All Objects should show correct properties and statistics. Most CREATE SQL is implemented, query tool seems to work smoothly including query cancelling (tested with 91k sized query). - F5 refresh - Ctrl-S save, Ctrl-O open and all SciTe keys - Alt-E Execute, Alt-X Explain (pgadmin style) - F5 Execute, Ctrl-Break Cancel (ms isql style) ***Missing, coming soon: - Aggregate, Operator, Function, Rule, Trigger CREATE SQL - functional index CREATE SQL - Column MODIFY SQL - comments - handling enhancements in sql tool - adding support for query builder *** Missing, currently I don't plan to implement (and no tool, editing a xrc file with a text editor isn't that fun): - object property dialogs - create object dialogs *** Enhancements I'm thinking of right now (coming soon): - split PG_FUNCTIONS into PT_FUNCTIONS AND PG_TRIGGERFUNCTIONS under PG_SCHEMA - show PG_TRIGGERFUNCTION under PG_TRIGGER - attempt to format CREATE VIEW output Regards, Andreas
> -----Original Message----- > From: Andreas Pflug [mailto:Andreas.Pflug@web.de] > Sent: 01 April 2003 00:20 > To: pgadmin-hackers@postgresql.org; Tom Lane; Keith > Subject: [pgadmin-hackers] pgadmin3: present and future > > > *** Missing, currently I don't plan to implement (and no > tool, editing a > xrc file with a text editor isn't that fun): No it's not :-). Actually I use XRCed which is written in wxPython. Found it somewhere on the wxWindows site. It's a bit quirky, but once you get the hang of it it works well. > - object property dialogs > - create object dialogs These are one and the same in pga2, the behaviour is modified based on whether an existing object is passed to the form. > > *** Enhancements I'm thinking of right now (coming soon): > - split PG_FUNCTIONS into PT_FUNCTIONS AND PG_TRIGGERFUNCTIONS under > PG_SCHEMA > - show PG_TRIGGERFUNCTION under PG_TRIGGER Not sure what you mean by this. Do you mean you want to move functions with a return type of TRIGGER to somewhere under the Triggers node? > - attempt to format CREATE VIEW output This would *definately* be easier to implement in PostgreSQL <shudders at the thought of writing another SQL parser>. I'll post a message to the hackers list... Regards, Dave.
Dave Page wrote: >This would *definately* be easier to implement in PostgreSQL <shudders >at the thought of writing another SQL parser>. I'll post a message to >the hackers list... > >Regards, Dave. > > > Too late, already done (at least a 96% solution). Regards, Andreas,
> -----Original Message----- > From: Andreas Pflug [mailto:Andreas.Pflug@web.de] > Sent: 01 April 2003 22:47 > To: Dave Page; pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] pgadmin3: present and future > > > Dave Page wrote: > > >This would *definately* be easier to implement in PostgreSQL > <shudders > >at the thought of writing another SQL parser>. I'll post a > message to > >the hackers list... > > > >Regards, Dave. > > > > > > > Too late, > already done (at least a 96% solution). That's alright. Tom Lane explained why it wouldn't work in the backend anyway... Regards, Dave.
Dave Page wrote: >That's alright. Tom Lane explained why it wouldn't work in the backend >anyway... > >Regards, Dave. > > > Dave, maybe you got me wrong. The CODING is already done... :-) Regards, Andreas
It's rumoured that Andreas Pflug once said: > Dave Page wrote: > >>That's alright. Tom Lane explained why it wouldn't work in the backend >>anyway... >> >>Regards, Dave. >> >> >> > Dave, > > maybe you got me wrong. > The CODING is already done... :-) No, I understood. I meant that it's OK you worked on it because Tom thought we had to do it that way. Though it now seems a possibility to add a new version of pg_get_viewdef(), which I might try to look at. But that's for another day... :-) /D