* Jeff Davis (pgsql@j-davis.com) wrote:
> On Tue, 2013-12-03 at 14:31 -0500, Tom Lane wrote:
> > Stephen Frost <sfrost@snowman.net> writes:
> > > When it comes to dump/reload, I'd much rather see a mechanism which uses
> > > our deep understanding of the extension's objects (as database objects)
> > > to implement the dump/reload than a text blob which is carried forward
> > > from major version to major version and may even fail to run.
> >
> > Note that we're already doing that in the binary_upgrade code path.
> > I agree that generalizing that approach sounds like a better idea
> > than keeping a text blob around.
>
> So does this take us fully back to Inline Extensions, or is there a
> distinction that I'm missing?
I've not really looked at the inline extensions patch/proposal in depth,
but I do think that's a lot closer than this. As I understand it,
Dimitri had a patch for this, though what I've found is the blog post.
Also, there were a lot of discussions about the idea a year or so ago,
including folks who haven't spoken up on this discussion.
> I still don't see that Extension Templates are all bad:
> * They preserve the fact that two instances of the same extension
> (e.g. in different databases) were created from the same template.
This is only true if we change the extension templates to be shared
catalogs, which they aren't today..
> * They mirror the file-based templates, so it seems easier to get
> consistent behavior.
While it might seem easier and perhaps simpler, I'm not sure that I
really buy into the idea that we'd actually be more consistent. Even if
we are, I'm not convinced that's what we want here.. The only thing
driving us in that direction is that we're calling these 'extensions'
too. While I don't want five different extension-like things, I'd
rather use a different name from 'extensions' if we feel that the
differences between catalog-only extensions and filesystem extensions
will cause 'extensions' overall to have terribly inconsistent behavior.
Thanks,
Stephen