On Fri, Dec 19, 2008 at 10:22 AM, Ashesh Vashi
<ashesh.vashi@enterprisedb.com> wrote:
> Dave Page wrote:
>
> On Fri, Dec 19, 2008 at 9:31 AM, Ashesh Vashi
> <ashesh.vashi@enterprisedb.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