Re: Patch: Add support for execution of jobs on a remote database

On Thu, Dec 18, 2008 at 12:25 PM, Ashesh Vashi
<ashesh(dot)vashi(at)enterprisedb(dot)com> wrote:
> Hi All,
>
> As per my discussion with Dave Page:

[for those that haven't realised, Ashesh is one of EDB's crack
programmers and is very kindly helping me out with some of the pgAdmin
work I don't currently have time for].

> - Add support for execution of jobs on a remote database in pgAgent.
> (primarily for hot standby support). This essentially means allowing a
> full connection string to be specified in place of the current database
> name option.

<snip comprehensive description>

Hi Ashesh,

I haven't tested fully at this stage, just eyeball reviewed the code,
made sure it builds (on Windows) and checked out the UI. First
impression is that it's well thought out and nicely implemented. I do
have a few comments though - mostly minor:

- The pgTable::HasColumn() static function seems like an unusual fit
in that class. Yes, it's a table object, but that class is primarily
concerned with representing a table in the treeview. It seems to me
that a non-static pgConn::TableHasColumn() function might make more
sense, and would probably look cleaner at the call sites.

- The database icon in dlgSelectDatabase seems to be missing (I just
get a blank space where it should be).

- The height of the connection string textbox is inconsistent with all
other textboxes. It should be sized as per the other one line text
boxes, and the button altered to match it.

- Any new headers should be added to include/precomp.h (we all forget
to do that!)

- In pgAgent, why is connInfo declared as a struct and not a class?

- pgAdmin seems to be able to handle connecting to an old-style schema
(which is good), but I didn't see any code in pgAgent to do similar. I
would suggest we do something like the following, which should allow
for future changes:

* Add an SQL function pgagent_schema_version() which returns an int
(with a value of 3 for this version - we'll bump the package to
3.0.0).

* Add a check to pgAgent in (MainLoop()) - upon setup of the primary
connection, if pgagent_schema_version() does not exist, then exit with
an error asking the user to upgrade the schema.

* If it does exist, check the value it returns against MAJOR_VERSION
- a pre-processor macro we can set in cmake from
CPACK_PACKAGE_VERSION_MAJOR - if it doesn't match, exit with an error
telling the user there is a schema version mismatch.

That should be fairly simple to implement, and nice and robust.

Thoughts?

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com