Re: btreecheck extension

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: btreecheck extension
Date: 2014-06-18 00:57:23
Message-ID: CAM3SWZQeH0O==c+UXOTQh5n0JBOzdjpf4WLaNYnVKBxrMfxJ6A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 17, 2014 at 5:11 PM, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2014-06-18 01:00:37 Re: Proposal for CSN based snapshots
Previous Message Bruce Momjian 2014-06-18 00:46:00 Re: pg_control is missing a field for LOBLKSIZE