Re: [PATCH] Store Extension Options

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?

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services