Howdy,

I'm working on functions to compare result sets for pgTAP. In the process, I found what appears to be an inconsistency in error handling when comparing incomparable results. I'm testing in 8.4RC2, but the issue may go back for all I know. Perhaps it's intentional?

This is what I see. This query:

    VALUES (1, 2), (3, 4) EXCEPT VALUES (1, 'foo'), (3, 'bar');

Throws 42804 DATATYPE MISMATCH. Meanwhile, this query:

    VALUES (1, 2), (3, 4) EXCEPT VALUES (1), (3);

Throws 42601 SYNTAX ERROR. It'd be nice if the error was a bit more specific (maybe tell me that there are different numbers of columns, perhaps 54011?), but at least it's distinct from the data type mismatch.

However, when I do a row-by-row comparison of rows in cursors, I get a different behavior. The attached test case has the details, but assuming a function `restults_eq(refcursor, refcursor)` that does the row-by-row comparison, this code:

    DECLARE cwant CURSOR FOR VALUES (1, 2), (3, 4);
    DECLARE chave CURSOR FOR VALUES (1, 'foo'), (3, 'bar');
    SELECT results_eq( 'cwant'::refcursor, 'chave'::refcursor );

Throws 42804 DATATYPE MISMATCH, as expected. On the other hand, this code:

    DECLARE cwant2 CURSOR FOR VALUES (1, 2), (3, 4);
    DECLARE chave2 CURSOR FOR VALUES (1), (3);
    SELECT results_eq( 'cwant2'::refcursor, 'chave2'::refcursor );

Also throws Throws 42804 DATATYPE MISMATCH. For consistency with the row comparisons done by EXCEPT and friends, should it not throw 42601 SYNTAX ERROR?

Thanks,

David


Attachment: try.sql
Description: Binary data




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to