Re: manage changes to views having depencies

From: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
To: "Eric Worden" <worden(dot)eric(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: manage changes to views having depencies
Date: 2009-01-01 05:09:50
Message-ID: dcc563d10812312109q66a5325ek11932bc49c70ba3d@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Dec 31, 2008 at 9:57 PM, Eric Worden <worden(dot)eric(at)gmail(dot)com> wrote:
> Can anyone recommend a reasonably efficient system for changing a view
> definition (say by adding a column) when it has a bunch of dependent
> functions?
>
> Right now I work with the output from pg_dump to recreate things after
> doing "DROP VIEW ... CASCADE". But the pg_dump schema output is only
> approximately sorted by dependencies, and "create table..." is
> sprinkled all through it. That means I have to carefully comb through
> and select the pieces I need.
>
> Is there a way to just script the view definitions, then the
> functions? Or maybe I'm looking at it the wrong way?

Last place we worked we had a little plpgsql script to drop all views.
How much and what kind of control you wanna build for that is up to
you. My guess is that this is an operation done during downtime, so
as not to impact users and allow for the code changes in the
application to be updated too. Or at least preceding it, and so you
can just dump all views and recreate them.

Then just have all your view create script ready to run. I'd keep
that as the standard, not what comes out of pg_dump's schema output.
Changes don't go into the test database or higher without going
through the view creation process.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Craig Ringer 2009-01-01 06:20:06 Re: postgres block_size problem
Previous Message Eric Worden 2009-01-01 04:57:09 manage changes to views having depencies