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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers