From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Guillaume Lelarge <guillaume(at)lelarge(dot)info>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Publish autovacuum informations |
Date: | 2015-01-01 22:17:33 |
Message-ID: | 20150101221733.GC2169761@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 31, 2014 at 12:46:17PM -0500, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Mon, Dec 29, 2014 at 11:03 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2015-01-02 03:09:49 | Re: Compression of full-page-writes |
Previous Message | Magnus Hagander | 2015-01-01 21:27:28 | Re: Additional role attributes && superuser review |