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:
http://www.postgresql.org/mailpref/pgsql-hackers
