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:19:42
Message-ID: 200208272119.g7RLJgC19841@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


Your patch has been added to the PostgreSQL unapplied patches list at:

http://candle.pha.pa.us/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

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

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

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2002-08-27 21:21:42 Re: [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
Previous Message Larry Rosenman 2002-08-27 21:17:07 Re: Proposed GUC Variable

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2002-08-27 21:19:56 Re: CREATE INDEX error message
Previous Message Larry Rosenman 2002-08-27 21:17:07 Re: Proposed GUC Variable