Re: [v9.2] DROP Reworks Part.0 - 'missing_ok' support of get_object_address
От | Robert Haas |
---|---|
Тема | Re: [v9.2] DROP Reworks Part.0 - 'missing_ok' support of get_object_address |
Дата | |
Msg-id | BANLkTinioMG8sFQoAwzmLGPQYM5LH=xUHg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [v9.2] DROP Reworks Part.0 - 'missing_ok' support of get_object_address (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [v9.2] DROP Reworks Part.0 - 'missing_ok' support of
get_object_address
|
Список | pgsql-hackers |
On Tue, Jun 21, 2011 at 11:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> Some of the refactoring you've done here seems likely to break things, >> because you're basically making the relation locking happen later than >> it does not, and that's going to cause problems. >> get_object_address_relobject() is a particularly egregious >> rearrangement. It seems to me that the right formula is to call >> relation_openrv() if missing_ok is false, and try_relation_openrv() if >> missing_ok is true. But that's sort of a pain, so I propose to first >> apply the attached patch, which gets rid of try_relation_openrv() and >> try_heap_openrv() and instead adds a missing_ok argument to >> relation_openrv() and heap_openrv(). If we do this, then the >> missing_ok argument can just be passed through all the way down. > >> Thoughts? Comments? Objections? > > At least the last hunk (in pltcl.c) seems to have the flag backwards. Ah, nuts. Sorry. I think that and parse_relation.c are the only places where the try variants are used; nobody else is willing to fail, and everyone else is passing false. Revised patch attached. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-hackers по дате отправления: