Re: [PATCH] Store Extension Options - Mailing list pgsql-hackers

Fabrízio de Royes Mello escribió:
> On Fri, Mar 7, 2014 at 5:56 PM, Alvaro Herrera <alvherre@2ndquadrant.com>wrote:
>
> > I am reworking this patch, both to accomodate earlier review comments
> > and to fix the multiple verify step of namespaces, as noted by Tom in
> > 4530.1390023795@sss.pgh.pa.us
> >
> Alvaro,
>
> Do you need some help?

Would you give this version of the patch a look?  I reworked your patch
a bit, mainly to add a bit of checking to custom namespaces.  In this
code, before you can add a namespaced option to an object, you need to
register the namespace.  There are two interfaces for this: C code can
call registerOptionNamespace().  This patch adds a call to plpgsql that
does so (It's not my intention that plpgsql is modified in any way by
this patch; this part of the patch is here just for demonstration purposes.)

I expect most extension modules would do things that way.

The other interface for namespace registration is a SQL-callable
function.  I expect Jim Nasby to do something like
  SELECT pg_register_option_namespace('decibel');
  ALTER TABLE nasby SET (decibel.seed = true);
which seems to cover what he wanted.

If you register a namespace, you can later do "ALTER TABLE .. SET
(yournsp.foobar=blah)" and your value will be stored in catalogs.  Note
that if you have a C module, you can register the options themselves,
using add_bool_reloption() and so on; that way, your option will be
type-checked.  If you don't "add" your options, they will not be
checked.  This is in line with what we do for custom GUCs: if we know
about them, they are checked, otherwise we just pass them around
untouched.

Note one weird thing related to TOAST tables: we need to tell
transformRelOptions specifically whether we want custom namespaces to be
kept in its output or not.  This is because we want such options in the
main table, but not in the toast table; and we call transformRelOptions
on both tables with the whole array of values.  That's what the new
"include_custom" bit is for.  For most callers that bit is true, but
when a table is being processed and the options are for the toast table,
that option is false.

Another thing to note is that I've separated the checking of the
namespaces from the transformation.  There's actually very little
duplicated work that we're saving from doing things that way AFAICS, but
the new interface does make more sense than the old one.  This is per
the thread I linked to previously.  (Note there is surely a better way
to do the HEAP_RELOPT_NAMESPACES than a #define with the "static const
char * const valid[]" thingy sprinkled all over the place; I assume we
can just declare that once in the header.  I will fix that later.)


I haven't touched pg_dump yet, but if this proposed design sits well
with everyone, my intention is that the dump output will contain the
pg_register_option_namespace() calls necessary so that a table
definition will be able to do the SET calls to set the values the
original table has, and succeed.  In other words, restoring a dump will
preserve the values you had, without a need of having the module loaded
in the new server.  I think this is what was discussed.  Robert, do you
agree?

I think there is more work to do here, mainly to ensure that the
internal representation makes sense for C users (i.e. can extensions get
at the values they previously set).  At this point I'm interested in
getting no objections to the SQL interface and the pg_dump bits.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services