Re: Step ordering pgAgent

Why is the trigger consistency so important for you? In my opinion triggers
have nothing to do with job steps. Other agent implementations (e.g.
sqlagent) also provides the ability to reorder steps.
Magnus, you're right there is no bug report on it. Could a reason for that
be that pgAgent isn't used on much installations?
.

2010/12/31 Magnus Hagander <magnus(at)hagander(dot)net>

> On Fri, Dec 31, 2010 at 15:38, Jasmin Dizdarevic
> <jasmin(dot)dizdarevic(at)gmail(dot)com> wrote:
> > Hi,
> > I'm starting another thread for this topic. You'll find the last comment
> > from Dave at the bottom.
> >> 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.
> >> 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
> >>> 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.
> >
> > What do others think? I'm still not convinced this is necessary - and
> > it certainly will become inconsistent with triggers.
>
> I think having explicit ordering would be good. For one thing, step
> ordering based on alphanumerics can actually differ depending on the
> servers locale, which is a receipie for "interesting bug reports".
>
> But it's certainly not *necessary* - we haven't had any such bug
> reports bubble up to this level (if it has happened to people they
> figured it out and solved it themeslves), and there is the trigger
> consistency. OTOH, triggers are actual database objects, so I think
> poeple are likely to make more restricted choices in naming them. And
> TBH, most installs will not have more than one trigger per table.
>
> --
> Magnus Hagander
> Me: http://www.hagander.net/
> Work: http://www.redpill-linpro.com/
>