Re: Add CREATE EXTENSION Support

From: Dave Page <dpage(at)pgadmin(dot)org>
To: "David E(dot) Wheeler" <david(at)justatheory(dot)com>
Cc: pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: Add CREATE EXTENSION Support
Date: 2014-01-30 13:52:10
Message-ID: CA+OCxox0msoJ9WQVbTZRiLZpfVNk7oB4LPtoBa8bM-Trt3zaKw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

On Fri, Jan 17, 2014 at 6:50 PM, David E. Wheeler <david(at)justatheory(dot)com> wrote:
> On Jan 16, 2014, at 5:39 PM, David E. Wheeler <david(at)justatheory(dot)com> wrote:
>
>> I hope to finish it up tomorrow. One quick question now, though: Do end users ever add records to pga_jobclass? Or are those 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, without cluttering 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 script also 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 existing 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 PostgreSQL servers where pgAgent itself isn't installed. Might it be worthwhile to also release an extension that just contains the SQL stuff and not pgAgent, so that it can be deployed to any server on which one might need to run CREATE EXTENSION pgagent?

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

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message Dave Page 2014-01-30 14:05:29 Re: Fixed some compiler warnings
Previous Message Akshay Joshi 2014-01-30 09:35:38 Fixed some compiler warnings