Re: [PATCH] Store Extension Options

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.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services