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 <robertmh...@gmail.com>: > On Mon, Jun 27, 2011 at 2:59 PM, Noah Misch <n...@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 <robertmh...@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 <kai...@kaigai.gr.jp>
pgsql-v9.2-drop-reworks-part-0.v5.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
