Re: [PATCH] Store Extension Options

<div dir="ltr"><div class="gmail_extra"><br />On Tue, Mar 11, 2014 at 2:43 PM, Simon Riggs <<a
href="mailto:simon@2ndquadrant.com">simon@2ndquadrant.com</a>>wrote:<br />><br />> On 11 March 2014 17:26,
AlvaroHerrera <<a href="mailto:alvherre@2ndquadrant.com">alvherre@2ndquadrant.com</a>> wrote:<br /> > > Tom
Laneescribió:<br />> >> Fabrízio de Royes Mello <<a
href="mailto:fabriziomello@gmail.com">fabriziomello@gmail.com</a>>writes:<br />> >> > You are correct.
pg_dumpexport reloptions using "WITH" clause of CREATE<br /> > >> > TABLE statement. I.e.:<br />>
>><br/>> >> > CREATE TABLE foo (<br />> >> > )<br />> >> > WITH
(autovacuum_enabled=false,bdr.do_replicate=false);<br />> >><br /> > >> > So if this statement
checksfor 'bdr' extension is loaded then in partial<br />> >> > restore it can be fail.<br />>
>><br/>> >> I see absolutely *nothing* wrong with failing that command if bdr is not<br /> > >>
installed. For an analogy, if this table includes a column of type bar<br />> >> defined by some extension
baz,we are certainly going to fail the<br />> >> CREATE TABLE if baz isn't installed.<br /> > >><br
/>>>> Now, if bdr is installed but the validation doesn't happen unless bdr<br />> >> is "loaded" in
somesense, then that is an implementation deficiency<br />> >> that I think we can insist be rectified before
thisfeature is accepted.<br /> > ><br />> > So, I spent some time on this patch the last couple of days to
addsome<br />> > validation.  But after submitting it, it seems to me that there wasn't<br />> > as much
consensuson how to handle validation than at first I thought.<br /> > ><br />> > So, the first and simplest
wayto go about this, of course, is just not<br />> > validate anything. This is what Fabrízio's patch does.  So
thetable<br />> > owner can execute<br />> >   ALTER TABLE mary SET
(supercalifragilisticexpialidocious.umbrella_flight= 'hell yeah')<br /> > > and that would be it.  Whether a
modulemakes use of this later or not,<br />> > is not that guy's problem.  This is mostly what we do for GUCs,
note,so<br />> > it's not exactly groundbreaking.<br /> ><br />> If a module fails to use a parameter that
maybe a problem. But<br />> forcing us to validate this using user written code may not improve<br />> the
situation.<br/>><br />> What happens if I have two extensions that both use the namespace foo?<br /> > That
meanswe would run two validation routines on it, and if they<br />> disagree on the set of options and values then
weare hosed.<br />><br />> -1 to *requiring* validation for table-level options for exactly the<br /> > same
reasonswe no longer validate custom GUCs.<br />><br /><br />In a previous email [1] I asked about alternatives to
drivethe work but unfortunately no one replied. So because we already do that to custom GUCs, and is the simpler way to
implementthis feature then I did that.<br /><br />Regards,<br /><br />[1] <a
href="http://www.postgresql.org/message-id/CAFcNs+r1ZXtRUZLEcEuJ1sF9Qr6Ciks7he-EsMkZOZnh4nxAUA@mail.gmail.com">http://www.postgresql.org/message-id/CAFcNs+r1ZXtRUZLEcEuJ1sF9Qr6Ciks7he-EsMkZOZnh4nxAUA@mail.gmail.com</a><br
/><br/>--<br />Fabrízio de Royes Mello<br />Consultoria/Coaching PostgreSQL<br />>> Timbira: <a
href="http://www.timbira.com.br">http://www.timbira.com.br</a><br/>>> Blog sobre TI: <a
href="http://fabriziomello.blogspot.com">http://fabriziomello.blogspot.com</a><br/> >> Perfil Linkedin: <a
href="http://br.linkedin.com/in/fabriziomello">http://br.linkedin.com/in/fabriziomello</a><br/>>> Twitter: <a
href="http://twitter.com/fabriziomello">http://twitter.com/fabriziomello</a></div></div>