Re: Temporary Views
От | Hannu Krosing |
---|---|
Тема | Re: Temporary Views |
Дата | |
Msg-id | 1029257417.4744.12.camel@rh72.home.ee обсуждение исходный текст |
Ответ на | Re: Temporary Views (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Temporary Views
Re: Temporary Views Re: Temporary Views |
Список | 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 по дате отправления: