Noah Misch-2 wrote
> On Fri, Dec 12, 2014 at 04:14:50PM -0500, Bruce Momjian wrote:
>> On Tue, Oct 21, 2014 at 01:38:43AM -0400, Noah Misch wrote:
>> > On Sat, Oct 18, 2014 at 02:23:46PM +0000, Bruce Momjian wrote:
>> > > doc: restrictions on alter database moving default tablespace
>> > >
>> > > Mention tablespace must be empty and no one connected to the
>> database.
>> >
>> > The database must not contain any object explicitly assigned to its
>> future
>> > default tablespace, but that tablespace need not be empty. Objects of
>> other
>> > databases in the tablespace pose no problem.
>>
>> I am back to look at this comment, and I don't understand what change is
>> being requested. Are you saying it is just the commit message that
>> isn't clear?
>>
>> The new text is:
>>
>> The new default tablespace for this database must be empty, and no one
>> can be connected to the database.
>>
>> That makes the distinction that only the tablespace for the existing
>> database has to be empty, not the entire tablespace.
>
> No, the commit message accurately describes the change. Your reply helps
> me
> understand your conception of the software's behavior, but I still read
> your
> committed documentation text differently. For "the new default tablespace
> for
> this database" to qualify as "empty", it must contain no object from any
> database. A tablespace is a cross-database, unitary object. Each
> tablespace
> is either empty from every perspective or not empty from any perspective.
> Here are a couple of alternatives for the documentation text:
>
> The new default tablespace must not already contain any of the
> database's
> objects, and no one can be connected to the database.
+1; though maybe...
The newly assigned default tablespace must not contain any of the specified
database's objects but otherwise need not be empty. Additionally, there
must not be anyone connected to the database.
This is a bit more verbose, and somewhat implied since newly created
databases have their default set, by definition, to one hat likely already
contains objects of other databases in the cluster, but does clarify the
specific confusion raised here. Re-reading I think the implicit version is
likely sufficiently clear though.
Side note: This implies you cannot change the default tablespace of the only
database in a cluster...probably not worth mentioning in the docs though.
David J.
--
View this message in context:
http://postgresql.nabble.com/pgsql-doc-restrictions-on-alter-database-moving-default-tablespace-tp5823550p5830836.html
Sent from the PostgreSQL - committers mailing list archive at Nabble.com.