On Mon, Jan 6, 2014 at 1:08 AM, Robert Haas <robertmh...@gmail.com> wrote: > > On Sun, Jan 5, 2014 at 3:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@gmail.com> writes: > >> On Sat, Jan 4, 2014 at 1:00 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >>> I would suggest addressing Robert's concern about lack of error checking > >>> by refusing to allow a custom reloption to be set unless the relevant > >>> extension is loaded and checks it. Unlike the postgresql.conf problem, > >>> I don't see any very good use-case for allowing an unchecked ALTER TABLE > >>> to occur. > > > >> How do you plan to resolve the associated dump/restore hazard? > > > > pg_dump creates extensions before tables, no? So what dump/restore > > hazard? > > Creating the extension doesn't guarantee that the shared library will > always be loaded. If nothing else, think about partial restores. >
You are correct. pg_dump export reloptions using "WITH" clause of CREATE TABLE statement. I.e.: CREATE TABLE foo ( ) WITH (autovacuum_enabled=false, bdr.do_replicate=false); So if this statement checks for 'bdr' extension is loaded then in partial restore it can be fail. At this point we have two choices: 1) do not check if extension already is loaded 2) hack the pg_dump to produce an "ALTER TABLE ... SET (...)" instead of "CREATE TABLE ... WITH (...)" to set reloptions Comments? -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL >> Timbira: http://www.timbira.com.br >> Blog sobre TI: http://fabriziomello.blogspot.com >> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello >> Twitter: http://twitter.com/fabriziomello