Re: [PATCH] Store Extension Options
От | Andres Freund |
---|---|
Тема | Re: [PATCH] Store Extension Options |
Дата | |
Msg-id | 20140313142056.GH8268@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: [PATCH] Store Extension Options (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [PATCH] Store Extension Options
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: [PATCH] Store Extension Options (Tom Lane <tgl@sss.pgh.pa.us>) Re: [PATCH] Store Extension Options (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On 2014-03-13 10:03:03 -0400, Robert Haas wrote: > On Thu, Mar 13, 2014 at 9:26 AM, Andres Freund <andres@2ndquadrant.com> wrote: > > On 2014-03-13 09:17:36 -0400, Robert Haas wrote: > >> It is very true that there are other ways for extensions to manage > >> per-table options. > > > > You previously said that, but I really don't see any. Which way out > > there exists that a) doesn't leave garbage after the relation is dropped > > or renamed b) is properly dumped by pg_dump c) is properly integratable > > with cache invalidations. > > > > c) is hackable by manually sending cache invalidations from C code when > > changing the associated information, and by using a relcache callback > > for cache invalidation, but the others really aren't solveable right now > > afaics. > > Well, I'm not going to claim that the methods that exist today are > perfect. Things you can do include: (1) the table of tables approach, > (2) abusing comments, and perhaps (3) abusing the security label > machinery. SECURITY LABEL FOR bdr ON TABLE copy_me IS 'yes, please'? > Only the first of those fails prong (a) of your proposed requirements, > and they all pass prong (b). I'm not totally sure how well comments > and security labels integrate with cache invalidation. The table of table fall short of all of those, so it's pretty much unusable. Comments aren't usable because there's no way to coordinate between various users of the facility and it breaks their original usage. They also don't produce cache invalidations. But security labels are a nice idea, will think about it. AFAICs there's no builtin subdivision within the label for one provider which is a bit of a shame but solvable. The biggest issue I see is that it essentially seems to require that the provider is in {shared,local}_preload_libraries? You can't restore into a server otherwise afaics? They currently don't seem to create invalidations on the objects they are set upon, maybe we should change that? There seems to be pretty little reason to avoid that, the frequence of change really should never be high enough for it to be problematic. > And an interesting point is that the SECURITY LABEL feature has been > around since 9.1 and we've had zero complaints about the design. This > either means that the design is excellent, or very few people have > tried to use it for anything. Without saying that its design is bad, I am pretty sure it's because it's basically unused. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Tom LaneДата:
Сообщение: Re: Patch: show relation and tuple infos of a lock to acquire