Robert Haas wrote: > On Fri, Jul 1, 2011 at 10:32 AM, Robert Haas <robertmh...@gmail.com> wrote: > > On Fri, Jul 1, 2011 at 8:06 AM, Amit Khandekar > > <amit.khande...@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.
Does this affect tables created during 9.1 beta? I assume a server restart fixes all this, but I am just checking. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
