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 -
"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, whic
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 loa
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 i
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 g
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
