Excerpts from Noah Misch's message of dom jul 22 17:11:53 -0400 2012:
> I was pondering something like this:
>
> setting "i-rc" "isolation" = "READ COMMITTED"
> setting "i-rr" "isolation" = "REPEATABLE READ"
>
> session "s1"
> setup { BEGIN TRANSACTION ISOLATION LEVEL :isolation; }
> step "foo" { SELECT 1; }
>
> permutation "i-rc" "foo"
> permutation "i-rr" "foo"
>
> That is, introduce psql-style variable substitutions in per-session "setup",
> "step" and "teardown" directives. Introduce the "setting" directive to
> declare possible values for each variable. Each permutation may name settings
> as well as steps. Order within the permutation would not matter; we could
> allow them anywhere in the list or only at the beginning. When the tester
> generates permutations, it would include all variable setting combinations.
The idea of using psql-style variables seems good to me.
Offhand having the setting names appear in permutations just like step
names seems a bit weird to me, though I admit that I don't see any other
way that's not overly verbose.
I would expect that if no permutations are specified, all possible
values for a certain setting would be generated. That way it'd be easy
to define tests that run through all possible permutations of two (or
more) sequences of commands on all isolation levels, without having the
specify them all by hand. With that in mind, having each possible value
for a setting be declared independently might be a bit troublesome.
Something like
setting "isolevel" "isolation" = { "READ COMMITTED", "REPEATABLE READ" } session "s1" setup { BEGIN
TRANSACTIONISOLATION LEVEL :isolation; } step "foo" { SELECT 1; } permutation "isolevel" "foo"
Maybe we can have a single name for both the setting specification and
variable name, instead of having to invent two names; in that case, it'd
reduce to
setting "isolation" = { "READ COMMITTED", "REPEATABLE READ" } session "s1" setup { BEGIN TRANSACTION
ISOLATIONLEVEL :isolation; } step "foo" { SELECT 1; } permutation "isolation" "foo"
Thoughts?
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support