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
