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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
