On Wed, Jun 11, 2014 at 4:46 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote:
> 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.) Are there a big problem with this implementation? I asked because we already do a strcmmp()'ing in 'buffering' option for GiST indexes since this commit http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5edb24a8. Regards, -- 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