| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Fabrízio de Royes Mello <fabriziomello(at)gmail(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:38:13 |
| Message-ID: | 20140102103813.GC22496@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2014-01-02 08:26:20 -0200, Fabrízio de Royes Mello wrote:
> 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 ???
Yea, right, it's autovacuum_...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christian Kruse | 2014-01-02 11:08:37 | Re: Patch: show relation and tuple infos of a lock to acquire |
| Previous Message | Andres Freund | 2014-01-02 10:37:54 | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |