On Wed, Jul 8, 2015 at 02:31:04PM +0100, Simon Riggs wrote: > On 7 July 2015 at 18:45, Sawada Masahiko <sawada.m...@gmail.com> wrote: > > On Wed, Jul 8, 2015 at 12:37 AM, Andres Freund <and...@anarazel.de> wrote: > > On 2015-07-07 16:25:13 +0100, Simon Riggs wrote: > >> I don't think pg_freespacemap is the right place. > > > > I agree that pg_freespacemap sounds like an odd location. > > > >> I'd prefer to add that as a single function into core, so we can write > >> formal tests. > > > > With the advent of src/test/modules it's not really a prerequisite for > > things to be builtin to be testable. I think there's fair arguments for > > moving stuff like pg_stattuple, pg_freespacemap, pg_buffercache into > > core at some point, but that's probably a separate discussion. > > > > I understood. > So I will place bunch of test like src/test/module/visibilitymap_test, > which contains some tests regarding this feature, > and gather them into one patch. > > > Please place it in core. I see value in having a diagnostic function for > general use on production systems.
Sorry to be coming to this discussion late. I understand the desire for a diagnostic function in core, but we have to be consistent. Just because we are adding this function now doesn't mean we should use different rules from what we did previously for diagnostic functions. Either their is logic to why this function is different from the other diagnostic functions in contrib, or we need to have a separate discussion of whether diagnostic functions belong in contrib or core. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
