Thread

  1. Re: [v9.2] DROP Reworks Part.0 - 'missing_ok' support of get_object_address

    Kohei KaiGai <kaigai@kaigai.gr.jp> — 2011-06-27T20:40:06Z

    The attached patch is rebased one towards the latest tree, using
    relation_openrv_extended().
    
    Although it is not a matter in this patch itself, I found a problem on
    the upcoming patch
    that consolidate routines associated with DropStmt.
    Existing RemoveRelations() acquires a lock on the table owning an
    index to be removed
    in the case when OBJECT_INDEX is supplied.
    However, the revised get_object_address() opens the supplied relation
    (= index) in same
    time with lookup of its name. So, we may break down the
    relation_openrv_extended()
    into a pair of RangeVarGetRelid() and relation_open().
    
    Any good idea?
    
    2011/6/27 Robert Haas <robertmhaas@gmail.com>:
    > On Mon, Jun 27, 2011 at 2:59 PM, Noah Misch <noah@leadboat.com> wrote:
    >> On Mon, Jun 27, 2011 at 01:28:30PM -0400, Robert Haas wrote:
    >>> On Wed, Jun 22, 2011 at 1:36 PM, Robert Haas <robertmhaas@gmail.com> wrote:
    >>> > I agree with you. ?If we had a whole pile of options it might be worth
    >>> > having heap_openrv() and heap_openrv_extended() so as not to
    >>> > complicate the simple case, but since there's no forseeable need to
    >>> > add anything other than missing_ok, my gut is to just add it and call
    >>> > it good.
    >>>
    >>> On further review, my gut is having second thoughts.  This patch is an
    >>> awful lot smaller and easier to verify correctness if I just mess with
    >>> the "try" calls and not the regular ones; and it avoids both
    >>> back-patching hazards for us and hoops for third-party loadable
    >>> modules that are using the non-try versions of those functions to jump
    >>> through.
    >>
    >> +1.  (Note that the function header comments need a few more updates.)
    >
    > Oh, good catch, thanks.  Committed with some further comment changes.
    >
    > --
    > Robert Haas
    > EnterpriseDB: http://www.enterprisedb.com
    > The Enterprise PostgreSQL Company
    >
    
    
    
    -- 
    KaiGai Kohei <kaigai@kaigai.gr.jp>