Re: [PATCH] Store Extension Options - Mailing list pgsql-hackers

<div dir="ltr"><div class="gmail_extra">On Tue, Mar 11, 2014 at 8:42 PM, Simon Riggs <<a
href="mailto:simon@2ndquadrant.com">simon@2ndquadrant.com</a>>wrote:<br />><br />> On 11 March 2014 18:33, Tom
Lane<<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>> wrote:<br /> > > Simon Riggs
<simon@2ndQuadrant.com>writes:<br />> >> -1 to *requiring* validation for table-level options for
exactlythe<br />> >> same reasons we no longer validate custom GUCs.<br />> ><br /> > > Well, that
isan interesting analogy, but I'm not sure how much it applies<br />> > here.  In the case of a GUC, you can
fairlyeasily validate it once the<br />> > module does get loaded (and before the module actually tries to do<br
/>> > anything with it).  I don't see how that's going to work for table<br />> > options.  I trust nobody
isseriously proposing that on module load, we're<br />> > going to scan the whole of pg_class looking to see if
thereare incorrect<br /> > > settings.  (Even if we did, what would we do about it?  Not try to force a<br />>
>pg_class update, for sure.  And what if the module is loading into the<br />> > postmaster thanks to a
preloadspec?)<br /> ><br />> Thank goodness for that. Strict validation does seem scary.<br />><br />> >
Idon't really think partial validation makes sense.  We could just remove<br />> > the whole topic, and tell
extensionauthors that it's up to them to defend<br /> > > themselves against bizarre values stored for their
tableoptions.  But I'm<br />> > wondering if there's really so much use-case for a feature like that.<br
/>><br/>> DBAs are fairly used to the idea that if you put crap data in the<br /> > database then bad things
happen.We provide the table, they provide<br />> the data. Validation is possible, but not enforced as essential.<br
/>>(Except in terms of the datatype - but then we are also validating<br /> > data to specific types here).<br
/>><br/>> So I think that DBAs will also cope rather well with table-level<br />> options without us nannying
them.<br/>><br />> There is nothing more annoying that needing to run scripts in a<br /> > specific sequence
tomake them work, or dumps that fail because<br />> certain modules aren't loaded yet (or cannot ever be so). And
maybe<br/>> the DBA wants to annotate tables based on a design and then later move<br /> > to implement modules
totake advantage of the annotation.<br />><br />> Having an option be set and yet be unvalidated and/or unused is
no<br/>> more annoying than having a column in a table that is known incorrect<br /> > and/or not accessed.
Searchingfor badly set options needs to be<br />> possible, even easy, but hard validation can cause problems. And
ifwe<br />> try and force it, whats to stop people from using a dummy validator<br /> > just to circumvent the
strictness?<br/>><br /><br /></div><div class="gmail_extra">Then I think my patch is more adherent given these
conclusions,except by the some adjustments suggested by Tom Lane and mentioned by Alvaro Herrera [1].<br /><br />Am I
correct?<br/><br /><br />[1] <a
href="http://www.postgresql.org/message-id/20140307205649.GF4759@eldon.alvh.no-ip.org">http://www.postgresql.org/message-id/20140307205649.GF4759@eldon.alvh.no-ip.org</a><br
/></div><divclass="gmail_extra"><br />--<br />Fabrízio de 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>