On Wed, Oct 20, 2010 at 8:37 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
I agree about the schema -- that's the whole point of the catalog tables.
I felt like the statistics were pretty marginal to begin with. There
may be a large number of places but there's no complex structure of
relationships to other tables or complex data structures going on
here. Surely they can all be coded to look up the relpages from
somewhere else just as easily?
But I'm not about to start working on this area so my judgement on how
much work that would be isn't very important here.
And your point that if we have a complete local copy of the entire
catalog schema then we can create temporary tables from whole cloth on
a read-only database
just as easily is attractive.
--
greg
