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

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> 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?

Yeah, well, I would have prefered to have two ways to fill-in the
templates then only work from the templates. That would solve the name
collision problem, and I guess would allow to share more code.

The other thing is that I want to support extensions that use both
models: say the prototype has been written in pl/pythonu but the next
version now is switching to C/.so…

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

Ok.

>> 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.

I already removed "directory" from that list beause once in the catalogs
you don't care where the files might have been found. MODULE_PATHNAME is
about how to read the script that we would store in the catalogs, not
sure we can bypass that.

> 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.

A template is something that needs to be instanciated with specific
parameters, and can get used any number of times with different sets of
parameters to build each time a new object. It's nothing like what we're
talking about, or I don't understand it at all.

My understanding is that we store the extension "sources" in our
catalogs so as to be able to execute them later. The only option we have
that looks like a template parameter would be the SCHEMA, the others are
about picking the right sources/script.

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

See above, my understanding of your proposal is not matching the
definition I know of that term.

>> 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).

I still can't help but thinking in terms of populating the "templates" one
way or the other and then using the "templates" to create or update the
extension itself.

We could maybe have a command akin to "yum update" or "apt-get update"
that would refresh the TEMPLATEs from disk (handling name conflicts,
file name parsing and control files parsing), and some options to the
EXTENSION commands to force a refresh before working?

So either

REFRESH EXTENSION TEMPLATES;
ALTER EXTENSION hstore UPDATE TO '1.2';

or

ALTER EXTENSION hstore UPDATE TO '1.2' WITH TEMPLATE REFRESH;

So my horrid proposal above would mean that the REFRESH option defaults
to true, and is also available to CREATE EXTENSION. I'm not sure how
much less horrid that makes it, but I sure hope it allows to better
explain / convey my vision about the thing.

>> 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.

Agreed.

> 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?).

What happens if the extension that was a created from a template is now
maintained on-disk (switch from pl/perlu to C)? What if the extension
that was on-disk because you couldn't use a template in 9.1 and 9.2 now
wants to be managed by the template system?

What if the PGXN guys think template are a perfect solution to integrate
into their client tool but the debian and yum packagers prefer to ship
disk-based extensions? And you want to switch from one packaging system
to the other?

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support