Re: SQL Macros in QueryTool.

[Dave Page <dpage(at)postgresql(dot)org>]

Hi Krzysiek,

Krzysztof Śmigrodzki wrote:
> Hello,
> I've been asked to add little macro capabilities to PgAdmin's QueryTool.

Excellent :-)

> My plans:

<snip>That all sounds pretty much as I imagined from Jan's original 
suggestion.

> Then I'll create configuration dialog. I've got some doubts how to 
> implement so expect question on the list.

Please feel free - we'll try to help as much as we can.

> If that will work, I think of defining different macro sets for 
> different server/databases (default macros for application, but they can 
> be overridden by macros specific to server or database).

Hmm, I'm not so sure about that. As someone who admin'ed quite a few 
databases at once in a previous life, it seems to me that per database 
or even per server macros could be quite confusing. I wonder if we could 
have macro 'sets' that weren't necessarily tied to a specific database 
or server, but could be selected independently.

> My development platform is:
> - Windows Vista Bussines x64, Polish
> - VC++ 2005 Express
> - wxWidgets 2.8.4 (current stable release)
> - PostgreSQL 8.2.4, default package from OpenBSD, run on virtual machine.

Why not use the local installation of PostgreSQL on Windows? You'll need 
it for the headers and libs anyway, and it'll save the overhead of 
running VMware or whatever.

> I'll start with revision 6393 of PGAdmin code. I'll build 32 bit code 
> (don't know if PGAdmin work in Windows 64 bit environment).

I don't think anyone ever tried to build a 64bit binary. I can't think 
of any major reason why it shouldn't work though, other than most of the 
dependency libraries being 32bit.

Anyhoo, I would advise that you develop against SVN trunk, and update on 
an almost daily basis. That makes it much easier to keep in sync - 
merging a much older tree can be much more difficult and laborious.

Oh, and just so you are aware - we've gone into feature freeze now for 
the upcoming release, so whilst you're free to develop (and we'll be 
happy to help you), no patches will be committed to SVN until after 
we've branched 1.8.

Regards, Dave.