Re: view reloptions - Mailing list pgsql-hackers

From Fabrízio de Royes Mello
Subject Re: view reloptions
Date
Msg-id CAFcNs+oPB9ktZC1yOVNs4VaMQnJBSKjHFKJg6njEg6GJ0X7FFA@mail.gmail.com
Whole thread Raw
In response to view reloptions  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers

On Wed, Jun 11, 2014 at 4:46 PM, Alvaro Herrera <alvherre@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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: view reloptions
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] Question about partial functional indexes and the query planner