On Fri, Jan 19, 2018 at 2:54 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Hmm ... so there's a small problem with this idea of dropping and > recreating template1: > > pg_restore: connecting to database for restore > pg_restore: dropping DATABASE template1 > pg_restore: [archiver (db)] Error while PROCESSING TOC: > pg_restore: [archiver (db)] Error from TOC entry 3024; 1262 1 DATABASE > template1 > postgres > pg_restore: [archiver (db)] could not execute query: ERROR: cannot drop a > templ > ate database > Command was: DROP DATABASE "template1"; > > Now in principle we could hack around that by issuing "ALTER DATABASE > ... IS_TEMPLATE false" first, but it turns out to be harder than you > might think to wedge that into the pg_dump infrastructure. (The > natural way to do it, trying to add this into the dropCmd for the > database TOC entry, fails because (a) DROP DATABASE then ends up as > one part of an implicit transaction block, and (b) it confuses the heck > out of pg_restore's --if-exists kluge.) > > You can actually exhibit this in current releases if you try "pg_dump > --clean --create" on a user-created template database, so it's not > solely the fault of this patch. > > What do people think of just removing this DROP DATABASE restriction? > Arguably, superusers should know better than to drop template1 anyway. > Maybe we should replace it with a hard-wired check against dropping > template0 (matched by name) just to stave off the worst-case scenario.
I think it's a little scary. The tail might be wagging the dog at this point. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
