On Wed, Dec 31, 2014 at 12:46:17PM -0500, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Mon, Dec 29, 2014 at 11:03 AM, Tom Lane <tgl@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.1230569070@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