If you try to test a procedure that includes transaction control statements (ie, COMMIT) using something like lives_ok() you'll get this confusing error:
died: 2D000: invalid transaction termination
The reason is that a procedure that executes transaction control establishes a "non-atomic execution context", but almost all other commands (including SELECT) establish an "atomic execution context".
The easy part of this would be to create procedure versions of useful tap functions (such as lives_ok() and throws_ok()).
The hard part would be figuring out how to get such a procedure to generate valid TAP output. RAISE is one obvious possibility, but it would depend on having client_min_messages set low enough. There'd also be an issue with the extra noise that RAISE generates.
Of course another problem would be support for xUnit / runtests() functionality.
If you try to test a procedure that includes transaction control statements (ie, COMMIT) using something like
lives_ok()you'll get this confusing error:died: 2D000: invalid transaction terminationThe reason is that a procedure that executes transaction control establishes a "non-atomic execution context", but almost all other commands (including SELECT) establish an "atomic execution context".
The easy part of this would be to create procedure versions of useful tap functions (such as lives_ok() and throws_ok()).
The hard part would be figuring out how to get such a procedure to generate valid TAP output. RAISE is one obvious possibility, but it would depend on having
client_min_messagesset low enough. There'd also be an issue with the extra noise that RAISE generates.Of course another problem would be support for xUnit / runtests() functionality.