Greg Stark <gsstark@mit.edu> writes:
> On Tue, Oct 19, 2010 at 4:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think they're more alike than you think. �If we had the infrastructure
>> to do local temp tables this way, it'd be pretty easy to use that to
>> instantiate per-backend copies of global temp tables. �(The global
>> entities would be templates, not actual tables.)
> Sure, but I think the idea was that you should be able to create
> temporary tables from whole cloth on the slave. Since they're local to
> the backend they never have to be stored on disk so logically from the
> user's point of view it seems like it should be possible.
The way I'm envisioning this working is that you instantiate temporary
child tables of all the system catalogs that are needed to describe
tables. Being system catalogs, their schemas never change, so you don't
have a problem there. Then you use these children to store the catalog
entries describing user temp tables. Whether those temp tables are
instantiations of spec-style global temp tables, or our current flavor
of local temp tables, won't matter.
I think it's pointless to speculate about whether we might have divvied
up the meta-information about tables differently if we'd foreseen
wanting to do this. It is what it is, and there is *way* too much code
depending on it, both inside the backend and in clients. Any
reimplementation of temp tables will still have to expose largely the
same catalog information that exists for tables now. We can probably
get away with marginal changes like redefining relfilenode, but we can't
avoid providing catalog entries that describe the schema and statistics
of a temp table.
regards, tom lane