Re: temporary views

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Tomasz Myrta <jasiek(at)lamer(dot)pl>, pgsql-sql(at)postgresql(dot)org
Subject: Re: temporary views
Date: 2001-10-08 03:23:19
Message-ID: 200110080323.f983NJn04420@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Bruce Momjian writes:
> >> * Allow views on temporary tables to behave as temporary views
>
> > I don't think this is a good idea. Especially since our temp tables are
> > allowed to shadow persistent tables, it would not be obvious whether the
> > view you're creating with any given statement will become persistent or
> > temporary.
>
> > I think an explicit CREATE TEMPORARY VIEW command would be fair and safe,
> > but until that is done we should probably concentrate on the SQL standard
> > behaviour.
>
> I agree with Peter on this --- CREATE TEMP VIEW seems like a fine idea,
> but allowing views to be implicitly made temporary sounds like a good
> way to shoot yourself in the foot. ISTM a plain CREATE VIEW should
> always create a permanent object, and therefore should error out if it
> refers to any temp tables.

We can handle the temp views thing two ways, either allow views to map
to temp tables by name, or allow temp views to map to temp tables that
exist at creation time and drop the views on session exit. The original
poster clearly wanted the first behavior, but I agree with Peter that
the second has fewer surprises for the user and is more standard.

I have updated the TODO item to:

* Allow temporary views

> However, there are some interesting implications here for the recurring
> issue of how plpgsql functions ought to interact with temp tables.
> We've generally thought of the current behavior as a simple shortcoming
> of plpgsql's query caching logic, and no doubt it is --- but what
> *should* the behavior be? Can a long-lived function validly refer to
> short-lived tables? If so, what should the semantics be, exactly?

It would be interesting of plpgsql could try for an table match by oid
first, and if that fails, try a match by table name and match only if a
temp table is hit. So basically the only table-name matching that would
happen would be hits on temp tables.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Janning Vygen 2001-10-08 08:30:01 Re: Problem with n to n relation
Previous Message Tom Lane 2001-10-08 02:53:11 Re: temporary views