Skip site navigation (1) Skip section navigation (2)

RE: [HACKERS] DROP TABLE inside a transaction block

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "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-09 00:43:35
Message-ID: 000001bf8960$8093d160$ (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> -----Original Message-----
> From: owner-pgsql-hackers(at)postgreSQL(dot)org
> [mailto:owner-pgsql-hackers(at)postgreSQL(dot)org]On Behalf Of Bruce Momjian
> > 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 ;-)
> >

I object to this proposal.

I have been suspicious why mapping algorithm from relations
to the relation file names is needed for existent relations.
This should be changed first.

And pluaral relation file names are needed for a relation oid/relname.
Why do you prefer fixed mapping oid/relname --> relation file name ?


Hiroshi Inoue

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-03-09 01:04:48
Subject: Re: [HACKERS] Transaction abortions & recovery handling
Previous:From: Peter EisentrautDate: 2000-03-09 00:38:20
Subject: Re: [BUGS] grant/revoke bug with delete/update

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group