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

Re: [HACKERS] pg_attribute.attisinherited ?

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)atentus(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>,pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] pg_attribute.attisinherited ?
Date: 2002-08-27 21:26:56
Message-ID: 200208272126.g7RLQuf20627@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Patch withdrawn by author.

---------------------------------------------------------------------------

Alvaro Herrera wrote:
> Tom Lane dijo: 
> 
> > Alvaro Herrera <alvherre(at)atentus(dot)com> writes:
> > > I'm thinking about the ONLY part in the grammar in ALTER TABLE... DROP
> > > COLUMN and RENAME COLUMN.  I think they should not be there:
> > 
> > Local DROP COLUMN is fine: it just causes the column to become
> > non-inherited in any children.  (Your patch for attisinherited will
> > need to cover this case.)
> 
> Oh, I see.
> 
> > Local RENAME COLUMN does need to be prohibited, as does local ADD
> > COLUMN, as does local ALTER COLUMN if we ever allow changing column
> > type.  Basically we need to prohibit the column from becoming
> > incompatible with its children.
> 
> > I don't agree with the notion of changing the grammar to achieve that,
> > btw.  Simpler and more friendly to add a specific error check in
> > (most likely place) utility/tcop.c.  Then if you try to say ONLY you'll
> > get a more useful complaint than "parse error".
> 
> Uh, I added checks in the command itself (command/tablecmds.c), just
> because I had already done so and to not make tcop/utility.c messier
> than it already is; I can probably move the check if people thinks it's
> better.  Also implemented is the change from inherited to non-inherited
> when local-dropping a column.
> 
> I also changed the text of some error messages from "renameatt: cannot
> foo" to "ALTER TABLE: cannot foo".  But my choose in wording of new
> error messages probably needs improvement (suggestions welcome).
> 
> Please review; I have not received comments on whether this
> implementation is a good approach: note the signature change of
> TupleDescInitEntry().
> 
> -- 
> Alvaro Herrera (<alvherre[a]atentus.com>)
> "La espina, desde que nace, ya pincha" (Proverbio africano)

Content-Description: 

[ Attachment, skipping... ]

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2002-08-27 21:27:20
Subject: Re: LWLockAcquire problems
Previous:From: Alvaro HerreraDate: 2002-08-27 21:25:35
Subject: Re: [HACKERS] pg_attribute.attisinherited ?

pgsql-patches by date

Next:From: Tom LaneDate: 2002-08-27 21:28:18
Subject: Re: [HACKERS] pg_attribute.attisinherited ?
Previous:From: Alvaro HerreraDate: 2002-08-27 21:25:35
Subject: Re: [HACKERS] pg_attribute.attisinherited ?

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