On Wed, Dec 29, 2010 at 6:55 PM, Jasmin Dizdarevic
> I've made the necessary changes to pgAdmin, but how do we handle schema
> version conflicts?
> pgAdmin's job UI now will not work with pgAgent schema version 3, because of
> the changes in pgagent.pga_job table. I think we have two possibilities:
> 1. Disable editing Jobs in pgAdmin until a schema upgrade is done
> 2. Check schema version during GetUpdateSql and GetInsertSql and return two
> different versions of the statement.
> What do you think?
I think 2. If the schema isn't of a high enough version, then the
appropriate controls on the UI should also be disabled. This is akin
to how we handle missing features in older versions of PostgreSQL
> I've got another two topics to discuss about pgAgent:
> 1. Step ordering
> I suggest adding a column named "jstorder" to pgagent.pga_jobsteps, so
> we don't have to rename the steps "A_", "B_" if an ordering is required. In
> the GUI we would add an integer field to the "Change Step" mask.
I'm not so keen on that - it could require some funky code to ensure
that the user uses sequential (or at least, non-duplicate) numbers
across all steps and would be a pain to upgrade to. Plus, there is
precedence for using alpha ordering - that's how triggers work
> 2. Definition from File
> Add an extra job step type "SQL from file". The definition field would
> be treated as a path to a file, which contains SQL-Statements.
That seems like a potentially useful feature.
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
In response to
pgadmin-hackers by date
|Next:||From: Dave Page||Date: 2010-12-29 19:27:10|
|Subject: Re: Keywords files|
|Previous:||From: Jasmin Dizdarevic||Date: 2010-12-29 18:55:38|
|Subject: Re: Email notification pgAgent|