Обсуждение: view reloptions

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

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Is it too late to redefine the check_option_offset stuff before 9.4
> ships, so that it is in its own struct?

We have a forced initdb already for beta2, so I'd say not.

> 3) I don't have time to do the legwork before CF1 anyway

... but if nobody does the work, it's moot.

> If we don't change it now, I'm afraid we'll be stuck with using
> StdRdOptions for views for all eternity.

Why would we not be able to change it in 9.5?  It's a catalog change,
sure, but we'll no doubt have others.
        regards, tom lane

On Wed, Jun 11, 2014 at 2: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.
>
[...]
> 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.)
>

Attached is a patch moving the reloptions of views into its own structure.
i also created a view_reloptions() function in order to not use
heap_reloptions() for views, but maybe that was too much?

i haven't seen the check_option_offset thingy yet, but i hope to take
a look at that tomorrow.

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
Phone: +593 4 5107566         Cell: +593 987171157

Jaime Casanova wrote:

> Attached is a patch moving the reloptions of views into its own structure.
> i also created a view_reloptions() function in order to not use
> heap_reloptions() for views, but maybe that was too much?

No, that was part of what I was thinking too -- I have pushed this now.
Many thanks.

> i haven't seen the check_option_offset thingy yet, but i hope to take
> a look at that tomorrow.

I'm guessing you didn't get around to doing this.  I gave it a quick
look and my conclusion is that it requires somewhat more work than it's
worth.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services