Re: btreecheck extension - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: btreecheck extension
Date
Msg-id CAM3SWZQeH0O==c+UXOTQh5n0JBOzdjpf4WLaNYnVKBxrMfxJ6A@mail.gmail.com
Whole thread Raw
In response to Re: btreecheck extension  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: btreecheck extension  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Tue, Jun 17, 2014 at 5:11 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> I think there's something to be said for that, but I think at the
> moment I like the idea of a functional interface better.  The reason
> is that I'm not sure we can predict all of the checks we're going to
> want to add.

That's true. Clearly this is very hand-wavy, and as I said I think
it's appropriate that the tool evolve in response to our testing
requirements, but I would like to figure out a way to have
verification tooling available for some kind of semi-standard tests,
possibly even including the standard regression tests. It's probably
too early to discuss, though.

> Now, we could.  We could come up with an extensible syntax, like this:
>
> CHECK relation [ USING { checktype [ '(' arg [, ...] '}' [, ...] ];

That's what I had in mind. Using the same trick that you came up with
for EXPLAIN, to avoid grammar bloat and let the am figure out for
itself what to name the various check types, with a generic default
check.


-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_control is missing a field for LOBLKSIZE
Next
From: Craig Ringer
Date:
Subject: Re: Proposal for CSN based snapshots