On 2014-02-13 14:40:39 -0300, Alvaro Herrera wrote:
> Andres Freund escribió:
> > On 2014-02-12 17:40:44 -0300, Alvaro Herrera wrote:
> > > > > Also, AutoVacOpts (used as part of reloptions) gained three extra
> > > > > fields. Since this is in the middle of StdRdOptions, it'd be somewhat
> > > > > more involve to put these at the end of that struct. This might be a
> > > > > problem if somebody has a module calling RelationIsSecurityView(). If
> > > > > anyone thinks we should be concerned about such an ABI change, please
> > > > > shout quickly.
> > > >
> > > > That sounds problematic --- surely StdRdOptions might be something
> > > > extensions are making use of?
> > >
> > > So can we assume that security_barrier is the only thing to be concerned
> > > about? If so, the attached patch should work around the issue by
> > > placing it in the same physical location.
> >
> > Aw. How instead about temporarily introducing AutoVacMXactOpts or
> > something? Changing the name of the member variable sounds just as
> > likely to break things.
>
> Yes, that's what I did --- see the attached patch, which I would apply
> on top of the code for master and would be only in 9.3. The idea here
> is to keep the existing bits of StdRdOpts identical, so that macros such
> as RelationIsSecurityView() that were compiled with the old rel.h
> continue to work unchanged and without requiring a recompile.
What I mean is that earlier code using StdRelOptions->security_barrier
directly now won't compile anymore. So you've changed a ABI breakage
into a API break. That's why I suggest adding the new options into a
separate struct at the end of StdRelOptions, that won't break anything.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
