Re: [PATCH] Store Extension Options

On Tue, Mar 11, 2014 at 8:42 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> On 11 March 2014 18:33, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> >> -1 to *requiring* validation for table-level options for exactly the
> >> same reasons we no longer validate custom GUCs.
> >
> > Well, that is an interesting analogy, but I'm not sure how much it
applies
> > here. In the case of a GUC, you can fairly easily validate it once the
> > module does get loaded (and before the module actually tries to do
> > anything with it). I don't see how that's going to work for table
> > options. I trust nobody is seriously proposing that on module load,
we're
> > going to scan the whole of pg_class looking to see if there are
incorrect
> > settings. (Even if we did, what would we do about it? Not try to
force a
> > pg_class update, for sure. And what if the module is loading into the
> > postmaster thanks to a preload spec?)
>
> Thank goodness for that. Strict validation does seem scary.
>
> > I don't really think partial validation makes sense. We could just
remove
> > the whole topic, and tell extension authors that it's up to them to
defend
> > themselves against bizarre values stored for their table options. But
I'm
> > wondering if there's really so much use-case for a feature like that.
>
> DBAs are fairly used to the idea that if you put crap data in the
> database then bad things happen. We provide the table, they provide
> the data. Validation is possible, but not enforced as essential.
> (Except in terms of the datatype - but then we are also validating
> data to specific types here).
>
> So I think that DBAs will also cope rather well with table-level
> options without us nannying them.
>
> There is nothing more annoying that needing to run scripts in a
> specific sequence to make them work, or dumps that fail because
> certain modules aren't loaded yet (or cannot ever be so). And maybe
> the DBA wants to annotate tables based on a design and then later move
> to implement modules to take advantage of the annotation.
>
> Having an option be set and yet be unvalidated and/or unused is no
> more annoying than having a column in a table that is known incorrect
> and/or not accessed. Searching for badly set options needs to be
> possible, even easy, but hard validation can cause problems. And if we
> try and force it, whats to stop people from using a dummy validator
> just to circumvent the strictness?
>

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].

Am I correct?

[1]
http://www.postgresql.org/message-id/20140307205649.GF4759@eldon.alvh.no-ip.org

--
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