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 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.
Thanks & Regards,
Ashesh Vashi
EnterpriseDB INDIA: http://www.enterprisedb.com
