Re: [HACKERS] DROP TABLE inside a transaction block
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] DROP TABLE inside a transaction block |
Дата | |
Msg-id | 200003082324.SAA07123@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] DROP TABLE inside a transaction block ("Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>) |
Ответы |
Re: [HACKERS] DROP TABLE inside a transaction block
RE: [HACKERS] DROP TABLE inside a transaction block |
Список | pgsql-hackers |
> Looked like it was going to be very simple: the RelationGetRelationName > and RelationGetPhysicalRelationName macros encapsulate access to the > (relation)->rd_rel->relname structure member pretty effectively (thanks > to Bruce's temp. relation work, I presume) Yes. > As a first crack, I decided to use the oid for the filename, just because > it simplified the chamges to the Macro, and there was already an oidout() > builtin that'd do the palloc for me ;-) > > <some time latter...> > > Well, ... it is, as they say, a Small Matter of Programming. I now know > a lot more about the bootstrap process, and the relcache, I can tell you! > > Most problems where code that used RelationGetPhysicalRelationName > when they it should use RelationGetRelationName. In several cases, > the code assumed RelationGetPhysicalRelationName handed them a > pointer to rd_rel->relname, which they copy into! I substituted > RelationGetRelationName for all these cases. Please send in a patch on those if they need to be corrected, OK? -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: