Re: Prep object creation hooks, and related sepgsql updates
От | Kohei KaiGai |
---|---|
Тема | Re: Prep object creation hooks, and related sepgsql updates |
Дата | |
Msg-id | CADyhKSWxyqkJhEpa7AGAEJQojR=F5Lj=RqLF3n3LyNGV1HZLHA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Prep object creation hooks, and related sepgsql updates (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Prep object creation hooks, and related sepgsql updates
|
Список | pgsql-hackers |
2011/12/3 Robert Haas <robertmhaas@gmail.com>: > On Fri, Dec 2, 2011 at 6:52 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote: >> At least, it is working. However, it is not a perfect solution to the >> future updates >> of code paths in the core. > > Hmm. So, do you want this committed? If so, I think the major thing > it lacks is documentation. > > I can't help noticing that this amounts, altogether, to less than 600 > lines of code. I am not sure what your hesitation in taking this > approach is. Certainly, there are things not to like in here, but > I've seen a lot worse, and you can always refine it later. For a > first cut, why not? Even if you had the absolutely perfect hooks in > core, how much would it save compared to what's here now? How > different would your ideal implementation be from what you've done > here? > You are likely right. Even if the hook provides sepgsql enough contextual information, it might means maintenance burden being moved to the core from sepgsql, as we discussed before. OK, I'd like to go with this approach. I'll try to update documentation stuff and regression test cases, so please wait for a few days. Thanks, > As regards future updates of code paths in core, nothing in here looks > terribly likely to get broken; or at least if it does then I think > quite a lot of other things will get broken, too. Anything we do has > some maintenance burden, and this doesn't look particularly bad to me. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company -- KaiGai Kohei <kaigai@kaigai.gr.jp>
В списке pgsql-hackers по дате отправления: