Hello Jim,
> If you want to ignore performance, there are things you can do with
> non-transactional variables that are simply not possible with tables. But
> even ignoring that, the performance cost of temp tables is massive compared
> to variables.
Ok, then read "variables are like tables" instead of "variables are
tables". Note that I'm definitely interested in performance in the end,
but I'm first interested in discussing features.
Currently I'm unconvinced by a proposal of variables that are in the
relation namespace (pg_class), are subject to GRANT/REVOKE, are managed
with CREATE/DROP *but* are somehow partly non transactional, and only
alive through sessions, and are only accessed through functions...
My current thinking is that the proposed design is either too heavy
(pg_class, permissions) or too light (then why not possible persistence
and/or transactions?): I would be more at ease with very light-weight
typed? session variables stored in the server process "as is", without any
attempt at pg_class & permissions, or with more full featured variables,
but not something half-baked which seems designed for a particular use
case that I do not have.
> Not only is the access far more complex, but bloating is a major problem
> (both in the table itself as well as in the catalog). That's part of the
> driver for all the discussion about things like permanent temp tables
> (which still leaves a bloat and performance problem in the table
> itself).
If a variable as currently discussed is in pg_class and subject to
permissions, then probably it will cost on the catalog side anyway, and at
least their existent would be transactional even if their value is not.
--
Fabien.