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?) 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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers