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@svana.org> 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@sss.pgh.pa.us> writes:
>>> On Mon, Jan 30, 2012 at 11:18 PM, Tom Lane<tgl@sss.pgh.pa.us> 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
