Обсуждение: pgScript plan
Hi pgAdmin hackers, Just as a reminder, pgScript is a Google Summer of Code project and my goal is to integrate it into pgAdmin. http://www.postgresqldocs.org/wiki/Gsoc08-pgscript ============= 1) Code reuse ============= This week I isolated some pgAdmin files that I am planning to reuse in the standalone version of pgScript: db pgConn pgQueryThread pgSet utils md5 misc I deleted a few things within those files in order to make them work with pgScript. I left the copyright notice at the top of each one. This should be OK since pgScript is also Artistic-licensed. ============== 2) Integration ============== I played with pgAdmin code and here is what I did: * I created a new icon and a new menu entry in the main window. * When this menu entry or icon is clicked, it opens a new form frmPgScript which is mainly based on frmQuery minus a few useless things (no Explain or History output, just a Run & Cancel button, ...). * This form is also based on ctlSQLBox but I added a m_pgscript data member to tell whether it is a pgScript ctlSQLBox or the regular one (Query tool); if it is pgScript one then, during instantiation, I add some keywords to the list of colorized keywords. So here are the files I modified: * ctlSQLBox.h * ctlSQLBox.cpp * frmMain.cpp The files I added: * frmPgScript.h * frmPgScript.cpp * pgs.xpm (icon) pgScript header files are supposed to be in pgadmin/include/pgscript directory. pgScript source files are supposed to be in pgadmin/pgscript directory. First, how does it sound? Am I completely wrong. Would you see something different? Then, if everything above is OK, I have several questions. Basically how would compilation be managed? I mean there are several possibilities: * Either pgScript can reside in pgAdmin repository or pgScript files would be provided as a patch (archive) and files would have to be added manually to pgAdmin. * If pScript resides in pgAdmin repository, how would users choose whether to compile pgAdmin with or without pgScript? Pre-processor symbol? This would be fine in order not to add the icon and the entry menu but would not prevent pgScript files (in include/pgscript/ and pgscript/) from being compiled even if they are not used. More generally I need your opinion about packaging. Best regards, Mickael
Hi Mickael On Mon, Jun 2, 2008 at 9:54 AM, Mickael Deloison <mdeloison@gmail.com> wrote: > I played with pgAdmin code and here is what I did: > * I created a new icon and a new menu entry in the main window. > * When this menu entry or icon is clicked, it opens a new form frmPgScript which > is mainly based on frmQuery minus a few useless things (no Explain or > History output, just a Run & Cancel button, ...). > * This form is also based on ctlSQLBox but I added a m_pgscript data member to > tell whether it is a pgScript ctlSQLBox or the regular one (Query tool); > if it is pgScript one then, during instantiation, I add some keywords to the > list of colorized keywords. ... > First, how does it sound? Am I completely wrong. Would you see something > different? It should not be a new form, but an enhancement to the existing one (just a 'run script' button, like we allready have run/explain/export etc). I can't see any justification for duplicating all the code that is likely still there (or increasing the complexity if you were to subclass it), and from a usability perspective it becomes very messy with two similar forms doing such similar jobs. > Then, if everything above is OK, I have several questions. Basically how would > compilation be managed? I mean there are several possibilities: > * Either pgScript can reside in pgAdmin repository or pgScript files would > be provided as a patch (archive) and files would have to be added manually > to pgAdmin. In the pgAdmin repo. > * If pScript resides in pgAdmin repository, how would users choose whether to > compile pgAdmin with or without pgScript? Pre-processor symbol? This would > be fine in order not to add the icon and the entry menu but would not prevent > pgScript files (in include/pgscript/ and pgscript/) from being compiled even > if they are not used. Why do you need to be able to disable it? If it's all in the source tree, then there's no reason that anyone should be able to turn it off - it's not like you need any additional libraries (do you?). Regards, Dave -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Dave Page wrote: > On Mon, Jun 2, 2008 at 9:54 AM, Mickael Deloison > <mdeloison@gmail.com> wrote: > > I played with pgAdmin code and here is what I did: > > * I created a new icon and a new menu entry in the main window. > > * When this menu entry or icon is clicked, it opens a new form > > frmPgScript which is mainly based on frmQuery minus a few useless > > things (no Explain or History output, just a Run & Cancel > > button, ...). > > * This form is also based on ctlSQLBox but I added a m_pgscript > > data member to tell whether it is a pgScript ctlSQLBox or the > > regular one (Query tool); if it is pgScript one then, during > > instantiation, I add some keywords to the list of colorized > > keywords. > ... > > First, how does it sound? Am I completely wrong. Would you see > > something different? > > It should not be a new form, but an enhancement to the existing one > (just a 'run script' button, like we allready have run/explain/export > etc). I can't see any justification for duplicating all the code that > is likely still there (or increasing the complexity if you were to > subclass it), and from a usability perspective it becomes very messy > with two similar forms doing such similar jobs. Absolutely. > > Then, if everything above is OK, I have several questions. > > Basically how would compilation be managed? I mean there are > > several possibilities: > > * Either pgScript can reside in pgAdmin repository or pgScript > > files would be provided as a patch (archive) and files would have > > to be added manually to pgAdmin. > > In the pgAdmin repo. I think this is very important. If it ends up being completely separate, it's not likely to get bundled on many platforms, if any. > > * If pScript resides in pgAdmin repository, how would users choose > > whether to compile pgAdmin with or without pgScript? Pre-processor > > symbol? This would be fine in order not to add the icon and the > > entry menu but would not prevent pgScript files (in > > include/pgscript/ and pgscript/) from being compiled even if they > > are not used. > > Why do you need to be able to disable it? If it's all in the source > tree, then there's no reason that anyone should be able to turn it off > - it's not like you need any additional libraries (do you?). Assuming it doesn't add a huge size increase to the binary, I agree - no reason to disable it. If it *should* be possible to disable it, it should be done within the framework of autoconf. //Magnus
2008/6/2 Magnus Hagander <magnus@hagander.net>: > Assuming it doesn't add a huge size increase to the binary, I agree - > no reason to disable it. If it *should* be possible to disable it, it > should be done within the framework of autoconf. > Hi Magnus, When compiled without the -g option, the standalone version binary is around 1.30 MB. I guess it is not too much since those 1,30 MB include pgConn.cpp, pgQueryThread.cpp, ... Mickael
Mickael Deloison wrote: > 2008/6/2 Magnus Hagander <magnus@hagander.net>: > > Assuming it doesn't add a huge size increase to the binary, I agree > > - no reason to disable it. If it *should* be possible to disable > > it, it should be done within the framework of autoconf. > > > > Hi Magnus, > > When compiled without the -g option, the standalone version binary is > around 1.30 MB. > I guess it is not too much since those 1,30 MB include pgConn.cpp, > pgQueryThread.cpp, ... That plus a bunch of wx linking overhead I'm sure. I think you should proceed under the assumption that it won't add too much to the pgAdmin binary, and that's the way to go. This still relies on it not requiring some exotic third party library though - if it does, it needs to be autoconf:ified. //Magnus