Hi, Sorry to be late in the thread, I'm too busy right now. Cédric called it to my immediate attention though. Martijn van Oosterhout <kleptog@xxxxxxxxx> writes: > Perhaps a better way of dealing with this is providing a way of dumping > extensions explicitly. Then you could say: > > pg_dump --extension=postgis -s That's something I'm working on in this commit fest under the “inline extensions” topic, and we should have that facility in 9.2 baring major obstacles (consensus is made). Tom Lane <tgl@xxxxxxxxxxxxx> writes: >>> On Mon, Jan 30, 2012 at 11:18 PM, Tom Lane<tgl@xxxxxxxxxxxxx> wrote: >>>> What's not apparent to me is whether there's an argument for doing more >>>> than that. It strikes me that the current design is not very friendly >>>> towards the idea of an extension that creates a table that's meant >>>> solely to hold user data --- you'd have to mark it as "config" which >>>> seems a bit unfortunate terminology for that case. Is it important to >>>> do something about that, and if so what? > > My thought exactly --- maybe it's only a minor cosmetic issue that will > affect few people, or maybe this will someday be a major use-case. > I don't know. I was hoping Dimitri had an opinion. So, being able to stuff data into an extension has been made possible to address two use cases: - postgis - (sql only) data extensions The former is very specific and as we didn't hear back from them I guess we addressed it well enough, the latter is still WIP. It's about being able to ship data as an extension (think timezone updates, geo ip, bank cards database, exchange rates, etc). You need to be able to easily ship those (CSV isn't the best we can do here, as generally it doesn't include the schema nor the COPY recipe that can be non-trivial) and to easily update those. The case for a table that is partly user data and partly extension data is very thin, I think that if I had this need I would use inheritance and a CHECK(user_data is true/false) constraint to filter the data. So I sure would appreciate being able to call that data rather than config, and to mark any table at once. If that doesn't need any pg_dump stretching I think providing that in 9.2 would be great. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
