Re: idea: storing view source in system catalogs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "David Fetter" <david(at)fetter(dot)org>, "Merlin Moncure" <mmoncure(at)gmail(dot)com>, "PG Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: idea: storing view source in system catalogs
Date: 2008-05-23 04:17:08
Message-ID: 8934.1211516228@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> Yeah. The current restrictions were set when CREATE OR REPLACE VIEW
>> was first implemented, and at that time we didn't have very much
>> ALTER TABLE capability at all; the view restrictions mirror what we
>> could do with a table at the time. It would be worth revisiting
>> that to make it square up with what you can now do to a table.

> I thought the problem had more to do with the former lack of query
> invalidation. If someone altered the view we had no way to replan any plans
> from a former definition of the view.

Well, we had no way to replan plans that depended on characteristics of
tables, either, which meant that ALTER COLUMN TYPE was a pretty
dangerous feature too before 8.3. I don't see that altering the output
column set of a view is really much different.

> Now that we have the query cache would we know that the view had changed and
> therefore the whole query needs to be replanned from source?

Yeah, it's isomorphic AFAICS.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira de Oliveira 2008-05-23 04:57:33 Re: BUG #4186: set lc_messages does not work
Previous Message Vishal Mailinglist 2008-05-23 03:23:23 Re: Error while executing pg_dump "invalid memory alloc request size 4294967293"