On Sat, 2013-12-14 at 13:46 -0800, Josh Berkus wrote:
> All:
>
> Can someone summarize the issues with this patch for those of us who
> haven't been following it closely? I was just chatting with a couple
> other contributors, and at this point none of just know what it
> implements, what it doesn't implement, what the plans are for expanding
> its feature set (if any), and why Frost doesn't like it. I tried
> reading through the thread on -hackers, and came away even more confused.
>
> Is there maybe a wiki page for it?
The patch offers an alternative to dropping files on the filesystem
before doing CREATE EXTENSION. Instead, if the extension has no C code,
you can put it in the catalog using ordinary SQL access, and execute the
same kind of CREATE EXTENSION. Aside from that, it's pretty much
identical to existing extensions.
Stephen doesn't like the idea that the SQL in an extension is a blob of
text. There are weird cases, like if you make local modifications to
objects held in an extension, then dump/reload will lose those local
modifications. Another issue, which I agree is dubious in many
situations, is that the version of an extension is not preserved across
dump/reload (this is actually a feature, which was designed with
contrib-style extensions in mind, but can be surprising in other
circumstances).
This isn't necessarily a dead-end, but there are a lot of unsettled
issues, and it will take some soul-searching to answer them. Is an
"extension" a blob of text with a version, that's maintained in some
external repo? Is it the job of postgres to ensure that dump/reload
creates the same situation that you started with, including local
modifications to objects that are part of an extension? Should
everything be an extension, or do we need to invent a new concept for
some of the use cases? What role to external tools play in all of this?
Regards,Jeff Davis