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
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 |