Re: in-catalog Extension Scripts and Control parameters (templates?)

Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> I think a separate kind of "extension template" object would make a lot
>> more sense.

> I'm on board now. We still have some questions to answer, and here's a
> worked out design proposal for implementing my understanding of your
> "extension's template" idea:

>  - Extension Scripts are now stored in the catalogs, right?

Only for these new-style thingies.  I am not suggesting breaking the
existing file-based implementation, only offering a parallel
catalog-based implementation too.  We'd have to think about what to do
for name collisions --- probably having the catalog entry take
precedence is okay, but is there an argument for something else?

> [ need separate catalogs for install scripts and update scripts ]

Check.

>    pg_extension_control(extension, version, default_version,
>                         default_full_version, module_pathname,
>                         relocatable, superuser, schema, requires)

Given that the feature is going to be restricted to pure-SQL extensions,
I'm pretty sure we can do without module_pathname, and maybe some other
things.

>  - The naming "TEMPLATE" appears to me to be too much of a generic
>    naming for our usage here, so I'm not sure about it yet.

Yeah, possibly, but I don't have a better idea yet.  I don't like
either PARAMETERS or SCRIPT --- for one thing, those don't convey the
idea that this is an object in its own right rather than an attribute of
an extension.

>    Oh actually TEMPLATE is already a keyword thanks to text search,

Actually, given the text search precedent, I'm not sure why you're so
against TEMPLATE.

>    That would mean that ALTER EXTENSION could create objects in other
>    catalogs for an extension that does not exists itself yet, but is now
>    known available (select * from pg_available_extensions()).

Man, that is just horrid.  It brings back exactly the confusion we're
trying to eliminate by using the "template" terminology.  We don't want
it to look like manipulating a template has anything to do with altering
an extension of the same name (which might or might not even be
installed).

> The $2.56 question being what would be the pg_dump policy of the
> "extension templates" objects?

The ones that are catalog objects, not file objects, should be dumped
I think.

> Now, my understanding is that CREATE EXTENSION would check for templates
> being already available in the catalogs and failing to find them would
> have to do the extra steps of creating them from disk files as a
> preparatory step, right? (backward compatibility requirement)

Wrong.  There is no reason whatsoever to load file-based stuff into
catalogs.  That just adds complication and overhead to cases that work
already, and will break update cases (what happens when a package update
changes the files?).

> I don't think we could easily match a .so with an extension's template
> so I won't be proposing that, but we could quite easily match them now
> with extensions, because we're going to have to LOAD the module while
> creating_extension = true.

One more time: this mode has nothing to do with extensions that involve
a .so.  It's for extensions that can be represented purely as scripts,
and thus are self-contained in the proposed catalog entries.
        regards, tom lane