Fwd: Email notification pgAgent - Mailing list pgadmin-hackers
From | Jasmin Dizdarevic |
---|---|
Subject | Fwd: Email notification pgAgent |
Date | |
Msg-id | AANLkTi=p-xuB2tsX5pkNC=OScjY+gTBnD10uQvwxROR-@mail.gmail.com Whole thread Raw |
In response to | Email notification pgAgent (Jasmin Dizdarevic <jasmin.dizdarevic@gmail.com>) |
Responses |
Re: Email notification pgAgent
|
List | pgadmin-hackers |
---------- Forwarded message ----------
From: Jasmin Dizdarevic <jasmin.dizdarevic@gmail.com>
Date: 2010/12/29
Subject: Re: [pgadmin-hackers] Email notification pgAgent
To: Dave Page <dpage@pgadmin.org>
Hi,
From: Jasmin Dizdarevic <jasmin.dizdarevic@gmail.com>
Date: 2010/12/29
Subject: Re: [pgadmin-hackers] Email notification pgAgent
To: Dave Page <dpage@pgadmin.org>
Hi,
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
across all steps and would be a pain to upgrade to. Plus, there is
precedence for using alpha ordering - that's how triggers work
I don't think that we must ensure that no duplicate values are used. With changing the "order by jstname,jstid" clause to "order by jstorder,jstname,jstid" we would have a fall back on alpha ordering.
Steps with "jstorder" = null would be executed last - so there is no need to upgrade. To give the user feedback about ordering in pgadmin, the steps could be ordered the same way in tree view and steps tab in job properties dialog. We could also add the jstorder-column to the list view.
2010/12/29 Dave Page <dpage@pgadmin.org>
Hi
On Wed, Dec 29, 2010 at 6:55 PM, Jasmin Dizdarevic<jasmin.dizdarevic@gmail.com> wrote:> Hi,I think 2. If the schema isn't of a high enough version, then the
> 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?
appropriate controls on the UI should also be disabled. This is akin
to how we handle missing features in older versions of PostgreSQL
itself.I'm not so keen on that - it could require some funky code to ensure
> 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.
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 workThat seems like a potentially useful feature.
> 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.
--Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
pgadmin-hackers by date: