From: | Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Scott Bailey <artacus(at)comcast(dot)net> |
Cc: | hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Invalidating dependent views and functions |
Date: | 2010-04-30 08:04:46 |
Message-ID: | 20100430170446.94EC.52131E4D@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Scott Bailey <artacus(at)comcast(dot)net> wrote:
> Problem: We need to change the last_name column of the people table from
> varchar(30) to varchar(50).
> Proposal: Add an invalid flag to pg_class.
Your example is one of the simplest cases, but there are other complex
usages. For example, shrinking varchar length, altering indexed columns,
CREATE FUNCTION RETURNS altered_table_type, and so on.
Can your proposal solve all (or almost all) use-cases? I think we need to
have such flag fields for each catalog tables if we support invalid status.
> ALTER TABLE people ALTER last_name VARCHAR(50) INVALIDATE;
> -- Alters column and invalidates any dependent objects
IMHO, I don't like the "invalid" flags. If we can recompile objects later,
why don't we recomple them at the same time?
ALTER TABLE people ALTER last_name TYPE varchar(50) CASCADE;
-- Alters column and *recompile* any dependent objects
However, dependent objects are not only in the database, but also in
the client applications. That's why we allow CREATE OR REPLACE VIEW
only to add columns, but disallow to modify existing columns.
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2010-04-30 08:43:43 | Re: pg_migrator to /contrib in a later 9.0 beta |
Previous Message | Scott Bailey | 2010-04-30 07:33:20 | Invalidating dependent views and functions |