Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

> > >>> I think the whole idea of a fast temporary table is that there
> > >>> are no catalog entries. If there are no catalog entries, then
> > >>> dependencies are not visible. If there ARE catalog entries, to
> > >>> what do they refer? Without a pg_class entry for the table,
> > >>> there's no table OID upon which to depend.
> >
> > >> TBH, I think that the chances of such a design getting committed
> > >> are not distinguishable from zero. Tables have to have OIDs;
> > >> there is just too much code that assumes that. And I seriously
> > >> doubt that it will work (for any large value of "work") without
> > >> catalog entries.
> >
> > > That seems a bit too defeatist.
> >
> > Huh? I didn't say we shouldn't work on the problem --- I just
> > think that this particular approach isn't good. Which you seemed
> > to agree with.
>
> I took your statement to mean that they need a pg_class entry - even
> if there were a partial solution to the pg_depend problem allowing to
> avoid pg_attribute entries, tha't still not really be a solution. If
> that's not what you mean, sorry - and nice that we agree ;)
>
>

Just to keep things sane I would like to remind that in this concrete
patch there _are_ catalog entries:

```
[...]
This file contents imlementation of special type of temporary tables ---
fast temporary tables (FTT). From user perspective they work exactly as
regular temporary tables. However there are no records about FTTs in
pg_catalog. These records are stored in backend's memory instead and
mixed with regular records during scans of catalog tables. We refer to
corresponding tuples of catalog tables as "in-memory" or "virtual"
tuples and to all these tuples together --- as "in-memory" or "virtual"
catalog.
[...]
```

As Tom pointed out a lot of PL/pgSQL code would stop working otherwise.
Also I mentioned that in this case even \d and \d+ would not work.

I personally find this discussion very confusing. Maybe we should
concentrate on a concrete patch instead of some abstract ideas, and
topics that are still open.

For instance it surprises me that apparently there is no one who
objects "lets make all temporary tables fast temporary tables" idea.
Since in this case code would use more memory for keeping a virtual
catalog wouldn't it be considered a major change of behavior that can
break someones production environment?

--
Best regards,
Aleksander Alekseev