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

From Fabrízio de Royes Mello
Subject Re: [PATCH] Store Extension Options
Date
Msg-id CAFcNs+pebdgZxXoZEYyQqM1KR2NOaMfvMV_F13eejxWh8yfWPQ@mail.gmail.com
Whole thread
In response to Re: [PATCH] Store Extension Options  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: [PATCH] Store Extension Options
List pgsql-hackers

On Thu, Jan 2, 2014 at 7:19 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>
> On 2013-12-31 13:37:59 +0100, Pavel Stehule wrote:
> > >  We use the namespace "ext" to the internal code
> > > (src/backend/access/common/reloptions.c) skip some validations and store
> > > the custom GUC.
> > >
> > > Do you think we don't need to use the "ext" namespace?
> > >
> >
> > yes - there be same mechanism as we use for GUC
>
> There is no existing mechanism to handle conflicts for GUCs. The
> difference is that for GUCs nearly no "namespaced" GUCs exist (plperl,
> plpgsql have some), but postgres defines at least autovacuum. and
> toast. namespaces for relation options.
>

autovacuum. namespace ???

The HEAP_RELOPT_NAMESPACES (src/include/access/reloptions.h) constant define only "toast" and "null" as a valid relation option namespace.

I missed something?

Regards,

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

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Next
From: Andres Freund
Date:
Subject: Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE