On Jan 16, 2014, at 5:39 PM, David E. Wheeler <david@justatheory.com> wrote:
> I hope to finish it up tomorrow. One quick question now, though: Do end users ever add records to pga_jobclass? Or
arethose five records supposed to be set in stone?
I changed it to exclude the five default classes by name rather than ID, which should be cleaner.
Attached is a patch implementing $subject. It's also viewable here:
https://github.com/theory/pgagent/compare/extension
I've also attached a patch to the pgAdminIII docs, viewable here:
https://github.com/theory/pgadmin3/compare/pgagent-extension
Please let me know how these look, of if you’d like any changes. The approach I took, BTW, was:
* Move the *.sql files to a sql/ directory. This is so that upgrade scripts can be created there in the future, too,
withoutcluttering up the root of the distribution.
* Add a cmake script to copy sql/pgagent.sql to pgagent--${VERSION}.sql, remove the BEGIN, COMMIT, and CREATE schema
lines,and uncomment lines that call pg_catalog.pg_extension_config_dump() to allow pgAgent table rows to be dumped. The
scriptalso replaces ${VERSION} in the control file.
* If Postgres supports extensions, add a target to call that script, and install commands for pgagent--${VERSION}.sql,
pgagent.control,and sql/*--*.sql in the server share/extensions directory.
* I also added sql/pgagent--unpackaged--3.3.0.sql so one can create the extension from unpackaged, which is useful for
existinginstallations. This file should be renamed to whatever the release version is that ships with this patch.
I think this is a relatively clean way to go. I'm wondering, though, whether the extension will be needed on PostgreSQL
serverswhere pgAgent itself isn't installed. Might it be worthwhile to also release an extension that just contains the
SQLstuff and not pgAgent, so that it can be deployed to any server on which one might need to run CREATE EXTENSION
pgagent?
Best,
David