From: | Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | Re: [PATCH] Store Extension Options |
Date: | 2014-02-14 00:44:56 |
Message-ID: | CAFcNs+rwDfOJqj6fecmytwT=dyqKucf1NDnnyATZf4BKGHSDww@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Feb 9, 2014 at 2:22 PM, Fabrízio de Royes Mello <
fabriziomello(at)gmail(dot)com> wrote:
>
>
> On Sat, Jan 11, 2014 at 2:47 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> >
> > On Sat, 2014-01-11 at 00:48 -0200, Fabrízio de Royes Mello wrote:
> > > > Now, if bdr is installed but the validation doesn't happen unless
> > > bdr
> > > > is "loaded" in some sense, then that is an implementation deficiency
> > > > that I think we can insist be rectified before this feature is
> > > accepted.
> > > >
> >
> > > Check if extension is already installed is not enough for the first
> > > version of this feature?
> >
> > Elsewhere it was argued that tying this to extensions is not
> > appropriate. I agree.
> >
> > It depends on how this feature is supposed to be used exactly. A
> > replication plugin might very well be loaded via
> > session_preload_libraries and not appear in SQL at all. In that case
> > you need some C-level hook. In another case, an extension might want to
> > inspect relation options from user-space triggers. So you'd need to
> > register some SQL-level function for option validation.
> >
> > This could end up being two separate but overlapping features.
> >
>
> Hi all,
>
>
> I taken this weekend to work on this patch and on monday or tuesday I'll
send it.
>
> But I have some doubts:
>
> 1) I'm not convinced to tying this to extensions. I think this feature
must enable us to just store a custom GUC. We can set custom GUCs in a
backend session using "SET class.variable = value", and this feature could
just enable us to store it for relations/attributes. Without the complexity
and overhead to register a function to validate them. That way we can use
this feature to extensions and other needs too.
>
> 2) If we're implement the Robert's idea to have a function to validate
the extension options then we must think about how a extension developer
will register this function. Beacuse when we install a extension must have
one way to get de pg_proc OID and store it in the pg_extension (or a
different catalog). Or we'll implement some way to register this function
at the SQL level, like "ALTER EXTENSION bdr SET VALIDATE FUNCTION
bdr_options_validate();" or another sintax of course.
>
> I don't know if you guys understood my concerns!! :-)
>
> Comments?
>
Hi all,
The attached patch implements the first option that I suggested before.
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
Attachment | Content-Type | Size |
---|---|---|
store-custom-reloptions_v1.patch | text/x-diff | 17.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-02-14 00:55:31 | Re: [bug fix] psql \copy doesn't end if backend is killed |
Previous Message | Tom Lane | 2014-02-14 00:39:04 | Re: Recovery inconsistencies, standby much larger than primary |