I just noticed by chance that view relations are using StdRdOptions to allocate their reloptions. I can't find any reason for this, other than someone failed to realize that they should instead have a struct defined of its own, just like (say) GIN indexes do. Views using StdRdOptions is quite pointless, given that it's used for stuff like fillfactor and autovacuum, neither of which apply to views.
9.2 added security_barrier to StdRdOptions, and 9.4 is now adding check_option_offset, which is a string reloption with some funny rules. Is it too late to redefine the check_option_offset stuff before 9.4 ships, so that it is in its own struct? (I'd hope we can redefine it in a simpler way also, hopefully one that doesn't require strcmp()'ing that string with "local" or "cascaded" every time someone is interested in knowing the option's value for a particular view.) There are some problems with this idea though, namely: 1) it's damn late in the release cycle already 2) it would mean that security_barrier would change for external code that expects StdRdOptions rather than, say, ViewOptions 3) I don't have time to do the legwork before CF1 anyway If we don't change it now, I'm afraid we'll be stuck with using StdRdOptions for views for all eternity. (It's a pity I didn't become aware of this earlier in 9.4 cycle when I added the multixact freeze reloptions ... I could have promoted a patch back then.) Thoughts? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers