Re: [HACKERS] pg_attribute.attisinherited ?
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] pg_attribute.attisinherited ? |
Дата | |
Msg-id | 200208272119.g7RLJgC19841@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] pg_attribute.attisinherited ? (Alvaro Herrera <alvherre@atentus.com>) |
Ответы |
Re: [HACKERS] pg_attribute.attisinherited ?
(Alvaro Herrera <alvherre@atentus.com>)
Re: [HACKERS] pg_attribute.attisinherited ? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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@atentus.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@postgresql.org -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-patches по дате отправления: