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

Re: Patch: Add support for execution of jobs on a remote database

From: "Dave Page" <dpage(at)pgadmin(dot)org>
To: "Ashesh Vashi" <ashesh(dot)vashi(at)enterprisedb(dot)com>
Cc: pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: Patch: Add support for execution of jobs on a remote database
Date: 2008-12-19 10:41:56
Message-ID: 937d27e10812190241t670b8210lf35bee92e8061b2@mail.gmail.com (view raw or flat)
Thread:
Lists: pgadmin-hackers
On Fri, Dec 19, 2008 at 10:22 AM, Ashesh Vashi
<ashesh(dot)vashi(at)enterprisedb(dot)com> wrote:
> Dave Page wrote:
>
> On Fri, Dec 19, 2008 at 9:31 AM, Ashesh Vashi
> <ashesh(dot)vashi(at)enterprisedb(dot)com> wrote:
>
>   * Add an SQL function pgagent_schema_version() which returns an int
> (with a value of 3 for this version - we'll bump the package to
> 3.0.0).
>
> I thought of this options too. :)
> Shouldn't we return a text instead of integer x.x.x support?
>
> I think we should tie the schema version to the major version number -
> so if we change the schema, we also bump the major version. That way
> we just need to represent the schema version with a single integer.
>
> My worries for this are:
> * When user upgrades from one pgagent to other, he/she will have to
> replicate
>   all the jobs in the new version.
> * We will have to code in the pgAdmin III for all version of pgAgent(s).
> * What if, user have two version of pgagent installed (as schema name is
> different
>   for each version, it can be possible), then what should be the behavior of
> the
>   pgAdmin III?
>
> I guess, it will be difficult to maintain in this case :(.
> What do you say?

I don't mean change the schema name, I mean change the design of the
schema (ie. add a column, or remove a table or something). The schema
name should always be pgagent so there should be no migration issues.

> I suppose we could tie it to the major.minor version - so 3.0.x ==
> 300, 3.1.x == 301, 4.0 == 400 and so on. That at least means we could
> change the schema in a minor release (which in pgAdmin/PostgreSQL
> aren't actually that minor usually!). The downside of this scheme is
> that it will be harder to set the macro in cmake.
>
> Agree.
> Only in case of schema change, we will have a change in major version.

OK.

-- 
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

In response to

Responses

pgadmin-hackers by date

Next:From: Ashesh VashiDate: 2008-12-19 10:45:48
Subject: Re: Patch: Add support for execution of jobs on a remote database
Previous:From: Ashesh VashiDate: 2008-12-19 10:22:07
Subject: Re: Patch: Add support for execution of jobs on a remote database

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