On 12/13/2011 12:29 PM, Julien Tachoires wrote:
2011/12/13 Robert Haas<robertmh...@gmail.com>:
On Tue, Dec 13, 2011 at 12:02 PM, Julien Tachoires<jul...@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    g...@2ndquadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to