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 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.gf4...@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
