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
