Re: SQL Macros in QueryTool.

From: Dave Page <dpage(at)postgresql(dot)org>
To: Krzysztof Śmigrodzki <ksmigrod(at)gmail(dot)com>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: SQL Macros in QueryTool.
Date: 2007-06-26 09:27:50
Message-ID: 4680DC16.1010605@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

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.

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message svn 2007-06-26 09:47:38 SVN Commit by dpage: r6394 - trunk/www/development
Previous Message Krzysztof Śmigrodzki 2007-06-26 08:54:27 SQL Macros in QueryTool.