[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] Publish autovacuum informations
From:       Tom Lane <tgl () sss ! pgh ! pa ! us>
Date:       2014-12-31 17:46:17
Message-ID: 21803.1420047977 () sss ! pgh ! pa ! us
[Download RAW message or body]

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.  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.

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".

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[prev in list] [next in list] [prev in thread] [next in thread]