On Tue, Mar 11, 2014 at 8:42 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 11 March 2014 18:33, Tom Lane <t...@sss.pgh.pa.us> wrote:
> > Simon Riggs <si...@2ndquadrant.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
> > 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,
> > going to scan the whole of pg_class looking to see if there are
> > 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
> > the whole topic, and tell extension authors that it's up to them to
> > themselves against bizarre values stored for their table options.  But
> > 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

Am I correct?


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

Reply via email to