On Fri, Jul 1, 2011 at 10:32 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Jul 1, 2011 at 8:06 AM, Amit Khandekar
> <amit.khandekar@enterprisedb.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 pg_temp.foo(a 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
