Re: relpersistence and temp table

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Amit Khandekar <amit(dot)khandekar(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: relpersistence and temp table
Date: 2011-07-12 01:55:29
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

Robert Haas wrote:
> On Fri, Jul 1, 2011 at 10:32 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > On Fri, Jul 1, 2011 at 8:06 AM, Amit Khandekar
> > <amit(dot)khandekar(at)enterprisedb(dot)com> wrote:
> >> In 9.1, if a table is created using an explicit pg_temp qualification,
> >> the pg_class.relpersistence is marked 'p', not 't'.
> >
> > That's a bug. ?Thanks for the report.
> OK, so I think the problem here is that, in 9.0, it was possible to
> figure out what value relistemp should take at a very late date,
> because it was entirely a function of the schema name. A temporary
> schema implies relistemp = true, while a non-temporary schema implies
> relistemp = false. However, in 9.1, that clearly won't do, since
> unlogged and permanent tables can share the same schema. Moreover, by
> the time we get as far as RelationBuildLocalRelation(), we've already
> made lots of other decisions based on relpersistence, so it seems that
> we need to make this correct as early as possible. It's not feasible
> to do that in the parser, because the creation namespace could also
> come from search_path:
> SET search_path = pg_temp;
> CREATE TABLE foo (a int);
> So it seems we can't fix this any earlier than
> RangeVarGetCreationNamespace(). In the attached patch, I took
> basically that approach, but created a new function
> RangeVarAdjustRelationPersistence() that does the actual adjusting
> (since de-constifying RangeVarGetCreationNamespace() didn't seem
> smart), plus adds a bunch of additional sanity-checking that I
> previously overlooked. Namely, it forbids:
> - creating unlogged tables in temporary schemas
> - creating relations in temporary schemas of other sessions
> On the other hand, it does allow CREATE TEMP TABLE int),
> which was somewhat pointlessly forbidden by previous releases. In
> short, the code now checks directly what it used to check by
> inference: that you're not creating a temporary table in a permanent
> schema, or the other way around.
> I also rearranged a few other bits of code to make sure that the
> appropriate fixups happen BEFORE we enforce the condition that
> temporary tables mustn't be created in security-restricted contexts.

Does this affect tables created during 9.1 beta? I assume a server
restart fixes all this, but I am just checking.

Bruce Momjian <bruce(at)momjian(dot)us>

+ It's impossible for everything to be true. +

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-07-12 02:02:59 Re: Deriving release notes from git commit messages
Previous Message Bruce Momjian 2011-07-12 01:34:18 Re: [COMMITTERS] pgsql: Enable CHECK constraints to be declared NOT VALID