Re: SQL objects UNITs (was: Extension Templates S03E11)

On Wed, Dec 18, 2013 at 10:05 AM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> Stephen Frost escribió:
>> * Dimitri Fontaine (dimitri(at)2ndQuadrant(dot)fr) wrote:
>
>> > Basically with building `UNIT` we realise with hindsight that we failed to
>> > build a proper `EXTENSION` system, and we send that message to our users.
>>
>> Little difficult to draw conclusions about what out 'hindsight' will
>> look like.
>
> I haven't been keeping very close attention to this, but I fail to see
> why extensions are so much of a failure. Surely we can invent a new
> "kind" of extensions, ones whose contents specifically are dumped by
> pg_dump. Regular extensions, the kind we have today, still wouldn't,
> but we could have a flag, say "CREATE EXTENSION ... (WITH DUMP)" or
> something. That way you don't have to come up with UNIT at all (or
> whatever). A whole new set of catalogs just to fix up a minor issue
> with extensions sounds a bit too much to me; we can just add this new
> thing on top of the existing infrastructure.

Yep.

I'm not very convinced that extensions are a failure. I've certainly
had plenty of good experiences with them, and I think others have as
well, so I believe Dimitri's allegation that we've somehow failed here
is overstated. That having been said, having a flag we can set to
dump the extension contents normally rather than just dumping a CREATE
EXTENSION statement seems completely reasonable to me.

ALTER EXTENSION foo SET (dump_members = true/false);

It's even got use cases outside of what Dimitri wants to do, like
dumping and restoring an extension that you've manually modified
without losing your changes.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company