Re: Temporary Views
От | Hannu Krosing |
---|---|
Тема | Re: Temporary Views |
Дата | |
Msg-id | 1029275120.4744.103.camel@rh72.home.ee обсуждение исходный текст |
Ответ на | Re: Temporary Views (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Wed, 2002-08-14 at 04:12, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Yes, I realize that, but when I create an index on a temp table, I can > > create it even though someone else tries to do the same in another > > session. If these views on temp tables go away on session exit, and > > can't be reliably accessed by other users, they should be in the temp > > schema and therefore invisible to other users and to prevent name > > conflicts. > > I think we should provide the *facility* for temp views; that doesn't > equate to feeling that we must have an enforcement mechanism to prevent > you from using a non-temp view on a temp table. The enforcement > mechanism would be notably more work to write and would slow down the > creation of views (at least non-temp ones), AFAIC we already have pg_depends, how much more work would it be to check that none of the tables a new view depends on are temp tables ? Both the table definitions and pg_depend entries should be still in cache. It should only be noticably slower in case we have to rollback the view creation for non-temp view on temp table case. I could live with error handling being a bit slow. > in order to achieve what? > Not much that I can see. Admittedly, it's a bit silly to use a > non-temp view with a temp table, but I don't think the system needs to > go out of its way to prevent silliness. It would be a pity to lose lots of views on connection close just because one of then happend to reference a temp table. If the view is in fact temporary (in the temporal sense ;) then it better be declared as such. Giving the least amount of surprise to users is always a good policy. > (Come to think of it, it might not be completely silly to do, either. > Suppose you want to use a temp table, but some legacy bit of code > insists on accessing the table using a fully-qualified schema name. > You could create a view foo.bar that references temp table baz, and > thereby bypass the fact that you don't know a schema name for baz. This seems to be a workaround for the fact that we store temp tables in their own schema. BTW, what does SQL standard say about using TEMP schemas for TEMP tables? > A bit far-fetched I agree, since if the legacy code is in your client > app you can probably fix it instead; but maybe there are more legitimate > uses.) You mean a scenario where the legacy client code creates a temp table but dont know how to access it ? Perhaps we should have SYNONYMS/ALIASES for such cases. They should act like symlinks. ------------- Hannu
В списке pgsql-hackers по дате отправления: