Re: [PATCH] Store Extension Options

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: [PATCH] Store Extension Options
Дата
Msg-id CA+U5nMK6R+a-V8zLggBR6FxN46n79p_GqMRVoFKeXZBMJuueFg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Store Extension Options  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: [PATCH] Store Extension Options  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
Re: [PATCH] Store Extension Options  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 11 March 2014 17:26, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Tom Lane escribió:
>> Fabrízio de Royes Mello <fabriziomello@gmail.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Atri Sharma
Дата:
Сообщение: Re: Why is AccessShareLock held until end of transaction?
Следующее
От: Joe Conway
Дата:
Сообщение: Re: Why is AccessShareLock held until end of transaction?