From 3a53e41d0e400559b3d4eb1b444e2ee0affd1ed7 Mon Sep 17 00:00:00 2001 From: "David E. Wheeler" Date: Tue, 10 Apr 2012 12:13:34 -0700 Subject: [PATCH] Fix broken `row_eq()` examples. --- Changes | 2 ++ doc/pgtap.mmd | 14 ++++++++------ 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/Changes b/Changes index 45af2740d..99a4aa270 100644 --- a/Changes +++ b/Changes @@ -8,6 +8,8 @@ Revision history for pgTAP [the report](https://github.com/theory/pgtap/issues/16). * Noted `pg_prove --verbose` for showing test descriptions and fixed a few typos in the documentation. Thanks to Jay Levitt for the pull request! +* Fixed broken examples in the `row_eq()` documentation. Thanks to @set5think + for the report! 0.90.0 2011-12-03T20:18:16Z --------------------------- diff --git a/doc/pgtap.mmd b/doc/pgtap.mmd index ebe9ebb8f..51cd546a3 100644 --- a/doc/pgtap.mmd +++ b/doc/pgtap.mmd @@ -1559,7 +1559,7 @@ created composite types and table types are supported. Thus, you can do this: name TEXT ); - SELECT row_eq( ROW(1, 'foo')::sometype, ROW(1, 'foo')::sometype ); + SELECT row_eq( $$ SELECT 1, 'foo' $$, ROW(1, 'foo')::sometype ); And, of course, this: @@ -1569,20 +1569,22 @@ And, of course, this: ); INSERT INTO users VALUES (1, 'theory'); + PREPARE get_user AS SELECT * FROM users LIMIT 1; - SELECT row_eq( id, name), ROW(1, 'theory')::users ) - FROM users; + SELECT row_eq( 'get_user', ROW(1, 'theory')::users ); Compatible types can be compared, though. So if the `users` table actually included an `active` column, for example, and you only wanted to test the `id` and `name`, you could do this: - SELECT row_eq( id, name), ROW(1, 'theory')::sometype ) - FROM users; + SELECT row_eq( + $$ SELECT id, name FROM users $$, + ROW(1, 'theory')::sometype + ); Note the use of the `sometype` composite type for the second argument. The upshot is that you can create composite types in your tests explicitly for -comparing the rerutn values of your queries, if such queries don't return an +comparing the return values of your queries, if such queries don't return an existing valid type. Hopefully someday in the future we'll be able to support arbitrary `record`