Simon Riggs <simon@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?)
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.
regards, tom lane