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

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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