Re: [SQL] temporary views
Bruce Momjian writes: > Seems like a TODO item, at least. What we could do is to create views > as TEMP if they use temp tables and drop the view as soon as the session > ends . You of course would have to recreate the view each time but > because it is a _temp_ view, it could be done reliably by multiple > backends at the same time. SQL requires that no table in a view declaration be a temporary table. > Added to TODO: > > * 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. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[SQL] PlPerl
1. Is there a plperlu? ... unsafe version of perl? 2. Is it possible to select which packages the plperl should have access to? 3. What exactly can you and can't you do. Thank you for your attention. Aasmund Midttun Godal [EMAIL PROTECTED] - http://www.godal.com/ +47 40 45 20 46 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [SQL] temporary views
Peter Eisentraut <[EMAIL PROTECTED]> 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. 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? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [SQL] PlPerl
On Mon, 8 Oct 2001, Aasmund Midttun Godal wrote: > 1. Is there a plperlu? ... unsafe version of perl? In 7.2, there will be. In 7.1, you have to apply patches manually. > 2. Is it possible to select which packages the plperl should have access to? In 7.2, plperlu can do anything. plperl in either version is very restricted. (use Safe qw(:default :math)) > 3. What exactly can you and can't you do. See above. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [SQL] temporary views
> Peter Eisentraut <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
