On Wed, Dec 31, 2014 at 12:46:17PM -0500, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Mon, Dec 29, 2014 at 11:03 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Either one of those approaches would cripple our freedom to change those > >> data structures; which we've done repeatedly in the past and will surely > >> want to do again. So I'm pretty much -1 on exposing them. > > > We could instead add a view of this information to core -- > > pg_stat_autovacuum, or whatever. > > > But to be honest, I'm more in favor of Guillaume's proposal. I will > > repeat my recent assertion that we -- you in particular -- are too > > reluctant to expose internal data structures to authors of C > > extensions, and that this is developer-hostile. > > Well, the core question there is whether we have a policy of not breaking > extension-visible APIs.
No, we have no policy restricting backend C API changes in major releases. Though this message is old enough to enroll in first grade, I know of no policy decision supplanting it: http://www.postgresql.org/message-id/8706.1230569...@sss.pgh.pa.us > While we will very often do things like adding > parameters to existing functions, I think we've tended to refrain from > making wholesale semantic revisions to exposed data structures. True. I especially look to avoid changes that will cause extensions to build and run, yet silently misbehave at runtime. For example, had I reviewed the pg_policy patch, I would have examined whether an unmodified 9.4 extension might let a user bypass relation policy. I oppose most header reorganization, which breaks builds in exchange for insubstantial benefits. I don't wish to extend that anywhere near to the point of saying, "Your C function can't use struct foo, because exposing struct foo in a header file would imply freezing it." Desire for backend API stability should not drive us to reject new functionality. > I'd be all right with putting the data structure declarations in a file > named something like autovacuum_private.h, especially if it carried an > annotation that "if you depend on this, don't be surprised if we break > your code in future". Such an annotation would be no more true than it is for the majority of header files. If including it makes you feel better, I don't object. nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers