Re: Add CREATE EXTENSION Support - Mailing list pgadmin-hackers

From Dave Page
Subject Re: Add CREATE EXTENSION Support
Date
Msg-id CA+OCxox0msoJ9WQVbTZRiLZpfVNk7oB4LPtoBa8bM-Trt3zaKw@mail.gmail.com
Whole thread Raw
In response to Re: Add CREATE EXTENSION Support  ("David E. Wheeler" <david@justatheory.com>)
Responses Re: Add CREATE EXTENSION Support  ("David E. Wheeler" <david@justatheory.com>)
List pgadmin-hackers
On Fri, Jan 17, 2014 at 6:50 PM, David E. Wheeler <david@justatheory.com> wrote:
> 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.

Those are really just defaults - users may well want to edit them to
their own requirements.

> 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

There's a missing word in there:

+If the server *is* 9.1 or later....

> 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
forexisting installations. This file should be renamed to whatever the release version is that ships with this patch. 

Looks like a good approach to me. I haven't tested mind you - just
eyeballed it at this stage.

> I think this is a relatively clean way to go. I'm wondering, though, whether the extension will be needed on
PostgreSQLservers where pgAgent itself isn't installed. Might it be worthwhile to also release an extension that just
containsthe SQL stuff and not pgAgent, so that it can be deployed to any server on which one might need to run CREATE
EXTENSIONpgagent? 

I think that's such a narrow use case, it's probably not worth doing.
You're more likely to have things the other way round - multiple
servers running the agent, all using a single database, which likely
also has a local agent instance.

Let me know when you're happy with the code and then I'll do a more
complete review with a view to committing.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgadmin-hackers by date:

Previous
From: Akshay Joshi
Date:
Subject: Fixed some compiler warnings
Next
From: Dave Page
Date:
Subject: Re: Fixed some compiler warnings