Re: Invalidating dependent views and functions

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

In response to

Browse pgsql-hackers by date

  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