Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Can we actually get rid of pg_class entries for temp tables. Maybe
creating a temp pg_class which would be local to each session? Heck,
it doesn't even have to be an actual table -- it just needs to be
somewhere from where we can load
Tom Lane [EMAIL PROTECTED] writes:
3. What about dependencies on user-defined types, functions, etc?
How will you get things to behave sanely if one backend tries to drop a
type that some other backend is using in a column of a temp table? Even
if you put entries into pg_depend, which would
On Thu, Jan 11, 2007 at 09:51:39PM -0500, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Can we actually get rid of pg_class entries for temp tables. Maybe
creating a temp pg_class which would be local to each session? Heck,
it doesn't even have to be an actual table -- it just
On Thu, 2007-01-11 at 16:11 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
It's not clear to me how this fix will alter the INSERT issue Kim
mentions.
I didn't say that it would; we have no information on the INSERT issue,
so I'm just concentrating on the problem that he did
Simon Riggs wrote:
Temp relations still make pg_class entried don't they? Is that on the
TODO list to change?
Yeah, and pg_attribute entries as well, which may be more problematic
because they are a lot. Did we get rid of pg_attribute entries for
system attributes already?
Can we actually
Alvaro Herrera [EMAIL PROTECTED] writes:
Can we actually get rid of pg_class entries for temp tables. Maybe
creating a temp pg_class which would be local to each session? Heck,
it doesn't even have to be an actual table -- it just needs to be
somewhere from where we can load entries into the
