Skip site navigation (1) Skip section navigation (2)

Re: Step ordering pgAgent

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Jasmin Dizdarevic <jasmin(dot)dizdarevic(at)gmail(dot)com>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Step ordering pgAgent
Date: 2010-12-31 14:49:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers
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

In response to


pgadmin-hackers by date

Next:From: Magnus HaganderDate: 2010-12-31 14:52:02
Subject: pgAdmin III commit: Re-indent source per new rules
Previous:From: Magnus HaganderDate: 2010-12-31 14:46:01
Subject: Re:

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group