Re: BUG #6205: ERROR: temporary tables cannot specify a schema name

On Wed, Sep 21, 2011 at 11:35 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Sun, Sep 18, 2011 at 5:10 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Thu, Sep 15, 2011 at 12:05 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> In that case I'm betting Robert broke it somewhere in the unlogged-table
>>>> changes.
>
>>> Yeah, looks like it.  Will investigate.
>
>> I committed a localized fix for this.  Basically, it now double-checks
>> that the schema name isn't the one that would have been forced by the
>> temp-ness, and doesn't throw an error if they match.
>
> Keeping in mind that this worked before ... did you take the approach of
> seeing exactly why it worked before, and why your changes broke it?
> The patch you committed looked like it was introducing the functionality
> from scratch, which should not have been the case.

See the commit message for 5da79169d3e9f0fab47da03318c44075b3f824c5,
and also the subsequent fix in
6f1be5a67a758499beab0082b6e63b3040913268.

I believe that the problem here is that we now need to set
relpersistence correctly much sooner than relistemp previously needed
to be hammered down. I think that in the 9.0 code, it was fine to
have a RangeVar with istemp = false and schemaname = pg_temp, and it
all worked itself out. For example, in 9.0,
RelationBuildLocalRelation() did this:

rel->rd_istemp = isTempOrToastNamespace(relnamespace);

Well, that trick doesn't work any more. In 9.0, you can infer the
persistence of the table from knowing what namespace it's in; and it
doesn't matter whether it ended up in that namespace because of an
explicit TEMP specification or because somebody gave a schema name of
pg_temp, or even a schema name of pg_temp_${MyBackendId}. But in 9.1,
that's no good: there are three possible relpersistence values, and
the namespace isn't enough to know what value has to be used. So it
must be passed in, which means that it must already be set correctly.
And setting it correctly earlier is knocking over the applecart.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company