Skip site navigation (1) Skip section navigation (2)

Re: Prep object creation hooks, and related sepgsql updates

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, PgHacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Prep object creation hooks, and related sepgsql updates
Date: 2011-12-03 08:43:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
2011/12/3 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Fri, Dec 2, 2011 at 6:52 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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.


> 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:
> The Enterprise PostgreSQL Company

KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

In response to


pgsql-hackers by date

Next:From: Albe LaurenzDate: 2011-12-03 11:02:13
Subject: Re: review: CHECK FUNCTION statement
Previous:From: NISHIYAMA TomoakiDate: 2011-12-03 08:24:44
Subject: Re: [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group