Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2010-04-30 08:43:43
Subject: Re: pg_migrator to /contrib in a later 9.0 beta
Previous:From: Scott BaileyDate: 2010-04-30 07:33:20
Subject: Invalidating dependent views and functions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group