Re: Temporary Views - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Temporary Views
Date
Msg-id 1029257417.4744.12.camel@rh72.home.ee
Whole thread Raw
In response to Re: Temporary Views  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Temporary Views  (Rod Taylor <rbt@zort.ca>)
Re: Temporary Views  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Temporary Views  (Hannu Krosing <hannu@tm.ee>)
List pgsql-hackers
On Tue, 2002-08-13 at 20:43, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I can go either way on this.
> 
> AFAICS "create temp view" would have some small advantage of keeping the
> view's name out of possibly-public permanent namespaces, so the step of
> just adding the TEMP option to CREATE VIEW may be worth doing.  The
> advantage isn't very big but neither is the amount of work.

Actually I think that having the views on any temp table also temp is
mandatory, or else these views will be broken in all other backends than
the one that created them (or expose other backends temp tables and are
thereby a security risk).

> Trying to prohibit non-temp views on temp tables strikes me as more work
> than it's worth;

What I would expect (if I had not read this thread and did not know
anything about PG's view implementation) would be that if view on temp
table was not defined temp itself, it would be automatically recompiled
on first use after the temp table was created in current session. So
forcing it to be explicitly declared TEMP would save me from that
mistake. 

I'd expect automatic recompilation of view to be done sometime in future
via saving view definition text, so that 'select * from t' would still
return all columns after "alter table t add column k"

> that TODO item was written before we had dependencies, and I think
> it's obsolete.  Basically the point of the TODO was to avoid
> having broken views --- and we have solved that problem.

We may have broken views again when "alter table drop column" gets done
.

----------
Hannu


pgsql-hackers by date:

Previous
From: strange@nsk.yi.org
Date:
Subject: Re: [GENERAL] Linux Largefile Support In Postgresql RPMS
Next
From: Hannu Krosing
Date:
Subject: Re: db partial dumping with pg_dump