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. > I guess if there are modules > that add extra stuff beyond StdRdOptions, this wouldn't work, but I'm > not really sure how likely this is given that our reloptions design > hasn't proven to be the most extensible thing in the world. Hm, I don't see how it'd be problematic, even if they do. I don't really understand the design of the reloptions code, but afaics, they shouldn't do so by casting around rd_options but by parsing it anew, right? 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
