I've committed the template0/template1 changes we were discussing
earlier. Plain pg_dump and pg_dumpall are changed to behave properly,
but I didn't touch pg_backup or pg_restore; can you deal with those?
regards, tom lane
At 13:39 14/11/00 -0500, Tom Lane wrote:
I've committed the template0/template1 changes we were discussing
earlier. Plain pg_dump and pg_dumpall are changed to behave properly,
but I didn't touch pg_backup or pg_restore; can you deal with those?
There's no such think as pg_backup, but
At 13:39 14/11/00 -0500, Tom Lane wrote:
I've committed the template0/template1 changes we were discussing
earlier. Plain pg_dump and pg_dumpall are changed to behave properly,
but I didn't touch pg_backup or pg_restore; can you deal with those?
I still think that pg_dump needs to use the
At 23:20 14/11/00 -0500, Tom Lane wrote:
Philip Warner [EMAIL PROTECTED] writes:
I still think that pg_dump needs to use the lastoid in template0 - did you
fail to implement this because you disagree, or because you think it should
use the current db lastsysoid?
I think it should use the
Philip Warner [EMAIL PROTECTED] writes:
Given the present backend coding, all the DBs in an installation will
have the same lastsysoid as template0 anyway, barring manual
intervention.
Not the way the current 'CREATE DATABASE' code works - remember the changes
to set the OID at create time?
At 23:48 14/11/00 -0500, Tom Lane wrote:
Philip Warner [EMAIL PROTECTED] writes:
Given the present backend coding, all the DBs in an installation will
have the same lastsysoid as template0 anyway, barring manual
intervention.
Not the way the current 'CREATE DATABASE' code works - remember
Here's what I'm planning to do to make the world safe for backup/restore
of user-added template1 data:
1. pg_database will have two new boolean columns, dbistemplate and
dballowconn --- if dballowconn is false then no new connections to that
database will be accepted. (An even better
Tom Lane wrote:
1. pg_database will have two new boolean columns, dbistemplate and
dballowconn --- if dballowconn is false then no new connections to that
database will be accepted. (An even better solution would be to make
a "dbisreadonly" attribute, but implementing such a thing
Lamar Owen [EMAIL PROTECTED] writes:
That is a great side-effect. Now, if there were a way to initdb just
template0, leaving everything else in place, then rebuilding template1
-- of course, a similar ability is there now, but the two-stage initdb
this implies could make pg_upgrade work
At 11:48 13/11/00 -0500, Tom Lane wrote:
5. pg_dump should ignore objects with OID = lastsysoid of the target
database.
I think it should ignore objects with OID = lastsysoid of template0; then
when it does a restore, it should use 'WITH TEMPLATE template0'. At least
this should be an
Philip Warner [EMAIL PROTECTED] writes:
5. pg_dump should ignore objects with OID = lastsysoid of the target
database.
I think it should ignore objects with OID = lastsysoid of template0; then
when it does a restore, it should use 'WITH TEMPLATE template0'.
Restores will be with template
Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
That is a great side-effect. Now, if there were a way to initdb just
template0, leaving everything else in place, then rebuilding template1
I'm missing something --- I don't see how this affects pg_upgrade one
way or the other, except
At 12:38 13/11/00 -0500, Tom Lane wrote:
I think it should ignore objects with OID = lastsysoid of template0; then
when it does a restore, it should use 'WITH TEMPLATE template0'.
Restores will be with template template0 anyway, but it seems to me that
dump should look to lastsysoid of the
13 matches
Mail list logo
