Re: Review: extension template

Hello Dimitri,

On 07/08/2013 11:49 AM, Dimitri Fontaine wrote:
> Please find attached to this mail version 9 of the Extension Templates
> patch with fixes for the review up to now.

Thanks, cool.

> Markus Wanner <markus(at)bluegap(dot)ch> writes:
>>> I still think that we shouldn't allow creating a template for an
>>> extension that is already installed, though. Do you have any suggestions
>>> for a better error message?
>>
>> If we go for the template model, I beg to differ. In that mind-set, you
>> should be free to create (or delete) any kind of template without
>> affecting pre-existing extensions.
>
> Then what happens at pg_restore time? the CREATE EXTENSION in the backup
> script will suddenly install the other extension's that happen to have
> the same name? I think erroring out is the only safe way here.

Extensions are commonly identified by name (installed ones as well as
available ones, i.e. templates).

Thus I think if a user renames a template, he might have good reasons to
do so. He likely *wants* it to be a template for a different extension.
Likewise when (re-)creating a template with the very same name of a
pre-existing, installed extension.

Maybe the user just wanted to make a "backup" of the template prior to
modifying it. If he then gives the new template the same name as the old
one had, it very likely is similar, compatible or otherwise intended to
replace the former one.

The file-system templates work exactly that way (modulo DSOs). If you
create an extension, then modify (or rename and re-create under the same
name) the template on disk, then dump and restore, you end up with the
new version of it. That's how it worked so far. It's simple to
understand and use.

> It's all about pg_restore really, but it's easy to forget about that and
> get started into other views of the world. I'll try to be better at not
> following those tracks and just hammer my answers with "pg_restore" now.

That's unlikely to be of much help. It's not like pg_restore would stop
to work. It would just work differently. More like the file-system
templates. More like the users already knows and (likely) expects it.
And more like the "template" model that you advertise.

Or how do you think would pg_restore fail, if you followed the mental
model of the template?

>> In any case, I'm arguing this "template" renaming behavior (and the
>> subsequent error) are the wrong thing to do, anyways. Because an
>> extension being linked to a parent of a different name is weird and IMO
>> not an acceptable state.
>
> Yes, you're right on spot here. So I've amended the patch to implement
> the following behavior (and have added a new regression test):
>
> # CREATE TEMPLATE FOR EXTENSION foo VERSION 'v' AS '';
> # CREATE EXTENSION foo;
> # ALTER TEMPLATE FOR EXTENSION foo RENAME TO bar;
> ERROR: 55006: template for extension "foo" is in use
> DETAIL: extension "foo" already exists
> LOCATION: AlterExtensionTemplateRename, template.c:1040
> STATEMENT: ALTER TEMPLATE FOR EXTENSION foo RENAME TO bar;

Okay, good, this prevents the strange state.

However, this also means you restrict the user even further... How can
he save a copy of an existing template, before (re-)creating it with
CREATE TEMPLATE FOR EXTENSION?

On the file system, a simple cp or mv is sufficient before
(re)installing the package from your distribution, for example.

>> I bet that's because people have different mental models in mind. But I
>> probably stressed that point enough by now...
>
> FWIW, I do agree.

Good. Why do you continue to propose the link model?

> But my understanding is that the community consensus
> is not going that way.

What way? And what community consensus?

Re-reading some of the past discussions, I didn't find anybody voting
for a dependency between the template and the created extension. And at
least Tom pretty clearly had the template model in mind, when he wrote
[1]: "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)." or [2]: "But conflating this functionality
[i.e. extension templates] with installed extensions is just going to
create headaches."

The closest I found was Robert Haas mentioning [3], that "[he doesn't]
see a problem having more than one kind of extensions". However, please
mind the context. He doesn't really sound enthusiastic, either.

I'm puzzled about some of your words in that thread. In the very message
Robert responded to, you wrote [4]: "Having more than one way to ship an
extension is good, having two different animals with two different
incompatible behaviors named the same thing is bad."

With the link-model, you are now proposing to create exactly that. Two
different kinds of extensions that are not compatible with each other.
One that is independent and one that depends on the "template" it got
created from.

>> Specifically, I request to either follow the template model more closely
>> (accompanied by a separate patch to adjust binary, out-of-line
>> templates) or follow the link model more closely. The current naming
>> doesn't match any of the two, so renaming seems inevitable.
>
> I think we need to follow the link model more closely because that's the
> consensus

If that's really the case - which I doubt at the moment - I'll certainly
accept that. I really recommend to rename the feature (and the
commands), in that case, though. We may rather call the existing
file-system thingie an "extension template", instead, as it becomes a
good differentiator to what you're proposing.

> and I will fix all the remaning discrepancies in between the
> two models that we can find.

How about ALTER EXTENSION ADD (or DROP)? With the link on the
"template", you'd have to prohibit that ALTER as well, based on the
exact same grounds as the RENAME: The installed extension would
otherwise differ from the "template" it is linked to.

See how this creates an animal pretty different from the current
extensions? And IMO something that's needlessly restricted in many ways.

> Please continue showing them to me!

Sure, I'm happy to continue reviewing.

Regards

Markus Wanner

[1]: Tom Lane, Re: in-catalog Extension Scripts and Control parameters
(templates?)
http://www.postgresql.org/message-id/6466.1354817682@sss.pgh.pa.us

[2]: Tom Lane, Re: Dumping an Extension's Script
http://www.postgresql.org/message-id/6466.1354817682@sss.pgh.pa.us

[3]: Robert Haas, Re: Dumping an Extension's Script
http://www.postgresql.org/message-id/CA+TgmoabcTrThHV5xe8BP_TE+2wqZGNn-8o4kzQSmkL2W9QY8Q@mail.gmail.com

[4]: Dimitri Fontaine: Re: Dumping an Extension's Script
http://www.postgresql.org/message-id/m2ehj4u7bz.fsf@2ndQuadrant.fr