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+r1ZXtRUZLEcEuJ1sF9Qr6Ciks7he-EsMkZOZnh4nxAUA@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Store Extension Options  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: [PATCH] Store Extension Options
List pgsql-hackers

On Sat, Jan 11, 2014 at 2:47 AM, Peter Eisentraut <peter_e@gmx.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?

Regards,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL

pgsql-hackers by date:

Previous
From: Marco Atzeri
Date:
Subject: Re: narwhal and PGDLLIMPORT
Next
From: Robert Haas
Date:
Subject: Re: Minor performance improvement in transition to external sort