Re: pgScript plan

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