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+rQD=j-TVf6zUOv3MJ3y2-dx1U9B9mLPrCudYCyk0Mm+g@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Store Extension Options  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: [PATCH] Store Extension Options
List pgsql-hackers
<div dir="ltr"><div class="gmail_extra"><br />On Tue, Dec 31, 2013 at 10:37 AM, Pavel Stehule <<a
href="mailto:pavel.stehule@gmail.com">pavel.stehule@gmail.com</a>>wrote:<br />><br />> 2013/12/31 Fabrízio de
RoyesMello <<a href="mailto:fabriziomello@gmail.com">fabriziomello@gmail.com</a>><br /> >><br />>> On
Tue,Dec 31, 2013 at 9:38 AM, Pavel Stehule <<a href="mailto:pavel.stehule@gmail.com">pavel.stehule@gmail.com</a>>
wrote:<br/>>> ><br />>> > 2013/12/31 Fabrízio de Royes Mello <<a
href="mailto:fabriziomello@gmail.com">fabriziomello@gmail.com</a>><br/> >> >><br />>> >> On
Tue,Dec 31, 2013 at 9:08 AM, Pavel Stehule <<a href="mailto:pavel.stehule@gmail.com">pavel.stehule@gmail.com</a>>
wrote:<br/>>> >> ><br />>> >> > Hello<br /> >> >> ><br />>> >>
>I am looking on this patch<br />>> >> ><br />>> >> > ALTER TABLE foo SET
(ext.somext.do_replicate=true);<br/>>> >> ><br />>> >> > Why is there fixed prefix "ext"
?<br/> >> >> ><br />>> >> > This feature is similar to attaching setting to function<br
/>>>>> ><br />>> >> > CREATE OR REPLACE FUNCTION ... SET var = ...;<br />>>
>>><br /> >> >> > We can use someprefix.someguc without problems there.<br />>> >>
><br/>>> >><br />>> >> Hi,<br />>> >><br />>> >> We use the prefix
"ext"(aka namespace) to distinguish these options which are related to "extensions".<br /> >> >><br
/>>>>> Have you seen the previous thread [1] ?<br />>> ><br />>> ><br />>> >
yes,but I don't understand why it is necessary? I use a analogy with custom GUC - and there we don't use similar
prefix.Only any prefix is required - and it can contain a dot.<br /> >> ><br />>><br />>> We use
thenamespace "ext" to the internal code (src/backend/access/common/reloptions.c) skip some validations and store the
customGUC.<br />>><br />>> Do you think we don't need to use the "ext" namespace?<br /> ><br />><br
/>>yes - there be same mechanism as we use for GUC<br />><br /><br />If we going to that way then we can expand
theuse of this patch to store custom GUCs to functions also, and we can wrote a function (like current_setting) to get
specificGUC values, like:<br /><br /></div><div class="gmail_extra">ALTER TABLE foo SET (myextension.option=on);<br
/></div><divclass="gmail_extra"><br />SELECT current_setting('foo'::regclass, 'myextension.option');<br /></div><div
class="gmail_extra"><br/></div><div class="gmail_extra">Comments?<br /></div><div class="gmail_extra"><br />--<br
/>Fabríziode Royes Mello<br />Consultoria/Coaching PostgreSQL<br />>> Timbira: <a
href="http://www.timbira.com.br">http://www.timbira.com.br</a><br/> >> Blog sobre TI: <a
href="http://fabriziomello.blogspot.com">http://fabriziomello.blogspot.com</a><br/>>> Perfil Linkedin: <a
href="http://br.linkedin.com/in/fabriziomello">http://br.linkedin.com/in/fabriziomello</a><br/> >> Twitter: <a
href="http://twitter.com/fabriziomello">http://twitter.com/fabriziomello</a></div></div>

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: PoC: Partial sort
Next
From: Simon Riggs
Date:
Subject: Re: Patch: show relation and tuple infos of a lock to acquire