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: AANLkTim8Tmksrev+BG9xX60M8CVKNhkjGVqmufBRkFAq@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message Magnus Hagander 2010-12-31 14:52:02 pgAdmin III commit: add rule for astyle run
Previous Message Magnus Hagander 2010-12-31 14:46:01 Re: code.pgadmin.org