Re: Don't cascade drop to view

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Erik Jones <erik(at)myemma(dot)com>
Cc: Sim Zacks <sim(at)compulab(dot)co(dot)il>, pgsql-general(at)postgresql(dot)org
Subject: Re: Don't cascade drop to view
Date: 2008-01-17 17:45:00
Message-ID: 20080117174500.GA21761@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Jan 17, 2008 at 11:10:25AM -0600, Erik Jones wrote:
> If you dropped tables out from under views, how would you expect them
> to act if someone were to query them? Inconsistent and unpredictable
> are just two words I'd use to describe a system that allowed that.

I'd expect it to throw an error that the tables are missing. I ran into
this today. All it really requires is that the view definition be
parsed at use time rather than at creation time.

> However, if these are relatively simple views, you may be able to get
> away with re-implementing them as functions that return sets of
> whatever record type your views are.

As you say, functions are compiled at use time, and hence don't suffer
this problem. You can build a view on the function and it should be
transparent...

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Those who make peaceful revolution impossible will make violent revolution inevitable.
> -- John F Kennedy

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Steve Clark 2008-01-17 17:53:14 pg_dumpall
Previous Message Erik Jones 2008-01-17 17:10:25 Re: Don't cascade drop to view