Re: [PATCH] Store Extension Options

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: [PATCH] Store Extension Options
Дата
Msg-id 20140313131753.GJ12995@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: [PATCH] Store Extension Options  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PATCH] Store Extension Options  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> I don't really think partial validation makes sense.  We could just remove
> the whole topic, and tell extension authors that it's up to them to defend
> themselves against bizarre values stored for their table options.  But I'm
> wondering if there's really so much use-case for a feature like that.

While I agree that validation would be a good thing to have, if we can
figure out a way to make it work, I don't really see why that has a huge
bearing on the use-cases for this feature overall.  There's clearly a
bunch of use-cases for "I need to add a bit of meta-data, for my own
needs, about this table."  Nasby is doing what Robert was originally
advocating (having an independent "table-of-tables") and rightfully
pointed out that it basically sucks.

I feel like a lot of this has to do with reloptions being in some
way/shape/form viewed as "ours" (as in, belongs to -core).  I can get
behind that idea, but it doesn't solve the use-case.  The whole
discussion around validation is interesting but it would also eliminate
a bunch of natural use-cases as not everyone will want to build an
extension or write C code just to have a place to store this extra
meta-data (and indeed- we'd probably just end up with someone
implementing a "custom_reloptions" extension which just allowed
anything).

In the end, perhaps we should just add another field which is called
'custom_reloptions' and allow that to be the "wild west"?  With a few
recommendations that extension authors use a prefix of some kind and
that individual DBAs use either no-namespace, or one which isn't likely
to conflict with real extensions.  That would also avoid any possible
conflict with what we want to do in core later on.  As for dealing with
extensions which migrate to core, we might be able to teach pg_dump's
binary upgrade about that, and be able to migrate any custom_reloptions
which were for the independent extension into the 'core' reloptions, or
we could just punt on it and tell people they'll need to re-set the
options or use whatever the new DDL is, or perhaps we'll update the
extension to just pass through the options.  In any case, that strikes
me as a solveable problem, particularly if they're independent fields.

Perhaps one other option would be to add a new field which is the 'wild
west' but then allow extensions to add to reloptions w/ appropriate
validation, but I'm not sure that it's really necessary.  Extensions
should be able to validate the value when they go to use it for
whatever they need it for and complain if they don't understand it.
Thanks,
    Stephen

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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: jsonb and nested hstore
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: gaussian distribution pgbench