On Wed, Nov 24, 2010 at 7:03 PM, Bruce Momjian <br...@momjian.us> wrote: > Daniel Farina wrote: >> On Wed, Nov 24, 2010 at 4:30 PM, Bruce Momjian <br...@momjian.us> wrote: >> > Robert Haas wrote: >> >> With respect to the syntax itself, I have mixed feelings. ?On the one >> >> hand, I'm a big fan of CREATE IF NOT EXISTS and DROP IF EXISTS >> >> precisely because I believe they handle many common cases that people >> >> want in real life without much hullabaloo. ?But, there's clearly some >> >> limit to what can reasonably be done this way. ?At some point, what >> >> you really want is some kind of meta-language where you can write >> >> things like: >> >> >> >> IF EXISTS TABLE t1 THEN >> >> ? ?ALTER TABLE t1 DROP CONSTRAINT IF EXISTS t1_constr; >> >> END IF; >> > >> > FYI, I have felt this way for a while. ?IF EXISTS seemed like something >> > that should never have been added as an inline SQL command option; it >> > just crept in, and kept growing. >> >> Okay, that being the case: would it make sense to have pg_dump emit DO >> blocks? I have a feeling this might draw fire, but I don't see any >> reason why the mechanism would not work to more or less equivalent >> effect. Certainly making dumps harder to use for those who insist on >> disabling PL/PGSQL is probably a negative side effect, if one can >> identify this hypothetical class of person. > > Not being able to recover a dump is serious problem for a user.
Even if it only involves enabling PLPGSQL to do the restore? Also take into consideration that plpgsql is enabled by default. A user would have to change the template database (which, in general, can cause restores to fail in at least a few other ways) or drop the procedural language explicitly to make that mechanism not work with a fresh and normal-looking createdb. -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
