Re: [PATCH] Store Extension Options

From: Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: [PATCH] Store Extension Options
Date: 2014-01-02 10:26:20
Message-ID: CAFcNs+pebdgZxXoZEYyQqM1KR2NOaMfvMV_F13eejxWh8yfWPQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 2, 2014 at 7:19 AM, Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-01-02 10:37:54 Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Previous Message Peter Geoghegan 2014-01-02 10:20:02 Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE