Re: Nonrecursive ALTER TABLE ADD/RENAME COLUMN is wrong

From: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Nonrecursive ALTER TABLE ADD/RENAME COLUMN is wrong
Date: 2002-06-25 02:19:06
Message-ID: 3D17D31A.66FF7DB1@fourpalms.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Fernando Nasser of Red Hat reminded me that it really makes no sense
> for ALTER TABLE ADD COLUMN and ALTER TABLE RENAME COLUMN to behave
> non-recursively --- that is, they should *always* affect inheritance
> children of the named table, never just the named table itself.

Hmm. Good point. Anything else would lead to structural breakage.

> The second seems more user-friendly but also seems to violate the
> principle of least surprise. Anyone have an opinion about what to do?

Same point as for the main issue: the solution should not introduce
structural breakage, especially only on the otherwise benign setting of
a GUC variable.

The case you are worried about already *has* structural inheritance, so
the GUC setting could reasonably have no effect. But if one is mixing a
database with inheritance structures with command settings that hide it,
they shouldn't be too suprised at whatever they get. The Right Thing
imho is to respect the underlying structures and definitions, not the
command facade. But would not dig in my heels on either choice after
more discussion.

- Thomas

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Curt Sampson 2002-06-25 03:32:05 Re: Index Scans become Seq Scans after VACUUM ANALYSE
Previous Message Rod Taylor 2002-06-25 02:16:21 Re: Nonrecursive ALTER TABLE ADD/RENAME COLUMN is wrong