On 12/13/2011 12:29 PM, Julien Tachoires wrote:
> 2011/12/13 Robert Haas<robertmhaas@gmail.com>:
>
>> On Tue, Dec 13, 2011 at 12:02 PM, Julien Tachoires<julmon@gmail.com> wrote:
>>
>>> Right, it seems to happen when the destination tablespace is the same
>>> as the database's tbs, because, in this case, relation's tbs is set to
>>> InvalidOid :
>>> src/backend/commands/tablecmds.c line 8342
>>>
>>> + rd_rel->reltablespace = (newTableSpace == MyDatabaseTableSpace) ?
>>> InvalidOid : newTableSpace;
>>>
>>> Why don't just asign newTableSpace value here ?
>>>
>> When a relation is stored in the default tablespace, we always record
>> that in the system catalogs as InvalidOid. Otherwise, if the
>> database's default tablespace were changed, things would break.
>>
> OK, considering that, I don't see any way to handle the case raised by Jaime :(
>
So we have a problem here: there's a case that's messy to handle. And
there's really a large issue hanging over this whole patch, which is
that it needs a better explanation of what exactly it's going to get
used for. Especially if the implementation gets more complicated, we'd
want to see a clear reason to use this feature. And that's not really
clear.
If you can return with an update that perhaps finds a way to work around
this OID issue, please re-submit that. And if you can explain some more
about where you think this feature is useful, more information on that
would be helpful. Since this isn't going to get committed soon, I'm
going to mark it returned with feedback for now.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us