Tom Lane wrote: > I think we have two choices: disallow foreign-key references from temp > tables to permanent tables, or take out the optimization of storing > temp table pages in private memory. (That would leave the whole "local > buffer manager" module as dead code, I think.) I'm kinda leaning > towards the first; does anyone feel that it's a valuable feature to keep?
I would hate to lose 'memory optimized' temp tables unless the arguments for were compelling and there was no other solution. > That is not the same bug; the problem here is that ON COMMIT DELETE ROWS > simply does an unconditional heap_truncate without bothering to run any > deletion triggers. We could make it apply the same checks TRUNCATE > TABLE does, whereupon you'd get some sort of "can't truncate table" > error when you try to set up a foreign key reference to it. That could > be extended to disallowing the FK reference in the first place, perhaps. > Or we could turn it into a "DELETE FROM temptable", which would be a lot > slower but would "do the right thing". Comments? This seems correct from one point of view, but what happens when a delete trigger fails? Instead of 'DELETE FROM', what about 'DROP...CASCADE'? This seems be consistent with other commands. For example, when a temp table has domain x and another backend does DROM DOMAIN...CASCADE on x, x is dropped from the temp table, which 'feels right'. If the temp table fails to drop for some reason, the memory could be bulldozed like it is now. BTW, domains are another way to bypass the 'isolation principle' for temp tables. Merlin ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
