On Wed, Jun 11, 2014 at 4:46 PM, Alvaro Herrera <alvhe...@2ndquadrant.com>

> 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


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

Reply via email to