Re: [HACKERS] DROP TABLE inside a transaction block

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: "Ross J(dot) Reedstrom" <reedstrm(at)wallace(dot)ece(dot)rice(dot)edu>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
Date: 2000-03-08 23:24:35
Message-ID: 200003082324.SAA07123@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-03-08 23:51:37 Re: [HACKERS] alter_table.sql
Previous Message Ross J. Reedstrom 2000-03-08 21:19:43 Re: [HACKERS] DROP TABLE inside a transaction block