Re: [PATCH] Store Extension Options

On Tue, Mar 11, 2014 at 2:43 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> On 11 March 2014 17:26, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> > Tom Lane escribió:
> >> =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= <fabriziomello(at)gmail(dot)com>
writes:
> >> > 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.
> >>
> >> I see absolutely *nothing* wrong with failing that command if bdr is
not
> >> installed. For an analogy, if this table includes a column of type bar
> >> defined by some extension baz, we are certainly going to fail the
> >> CREATE TABLE if baz isn't installed.
> >>
> >> Now, if bdr is installed but the validation doesn't happen unless bdr
> >> is "loaded" in some sense, then that is an implementation deficiency
> >> that I think we can insist be rectified before this feature is
accepted.
> >
> > So, I spent some time on this patch the last couple of days to add some
> > validation. But after submitting it, it seems to me that there wasn't
> > as much consensus on how to handle validation than at first I thought.
> >
> > So, the first and simplest way to go about this, of course, is just not
> > validate anything. This is what Fabrízio's patch does. So the table
> > owner can execute
> > ALTER TABLE mary SET
(supercalifragilisticexpialidocious.umbrella_flight = 'hell yeah')
> > and that would be it. Whether a module makes use of this later or not,
> > is not that guy's problem. This is mostly what we do for GUCs, note, so
> > it's not exactly groundbreaking.
>
> If a module fails to use a parameter that may be a problem. But
> forcing us to validate this using user written code may not improve
> the situation.
>
> What happens if I have two extensions that both use the namespace foo?
> That means we would run two validation routines on it, and if they
> disagree on the set of options and values then we are hosed.
>
> -1 to *requiring* validation for table-level options for exactly the
> same reasons we no longer validate custom GUCs.
>

In a previous email [1] I asked about alternatives to drive the work but
unfortunately no one replied. So because we already do that to custom GUCs,
and is the simpler way to implement this feature then I did that.

Regards,

[1]
http://www.postgresql.org/message-id/CAFcNs+r1ZXtRUZLEcEuJ1sF9Qr6Ciks7he-EsMkZOZnh4nxAUA@mail.gmail.com

--
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