Re: SQL objects UNITs (was: Extension Templates S03E11)
От | Robert Haas |
---|---|
Тема | Re: SQL objects UNITs (was: Extension Templates S03E11) |
Дата | |
Msg-id | CA+TgmoZLAeNpg2w4TqsgVjBoQHD_EmdDW1RB_rZ0Bwh_x7pPrw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: SQL objects UNITs (was: Extension Templates S03E11) (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: SQL objects UNITs
Re: SQL objects UNITs (was: Extension Templates S03E11) |
Список | pgsql-hackers |
On Wed, Dec 18, 2013 at 10:05 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Stephen Frost escribió: >> * Dimitri Fontaine (dimitri@2ndQuadrant.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
В списке pgsql-hackers по дате отправления: