Re: Inconsistent Errors on Row Comparisons

On Jun 30, 2009, at 11:18 AM, Tom Lane wrote:

> So really what you're wishing for is that we treat different-numbers- 
> of-
> columns as a whole new SQLSTATE inside category 42.  What's the  
> argument
> for needing to handle this differently from DATATYPE_MISMATCH?

For my results_eq() in pgTAP, it could output different diagnostics.  
I'm already doing this for the set_eq() function I wrote, which uses  
EXCEPT. For that function, if you pass two statements with different  
numbers of columns, pgTAP says:
    # Failed test 148    #     Number of columns differs between queries

While for a call with the same numbers of columns but different data  
types (say int,text and inet,text), pgTAP says:
    # Failed test 149    #     Column types differ between queries

Essentially, while on a row object-level, they are different types,  
the caller of my function doesn't know that it's comparing rows, just  
that it's comparing result sets. So I like to give as much information  
as possible about the difference in the result sets of the queries.  
Hell, ideally it'd actually say something like:
    # Failed test 148    #     Number of columns differs between queries    #         have: 4 columns    #
want:3 columns
 
    # Failed test 149    #     Column types differ between queries    #         have: (integer,text)    #         want:
(inet,text)

This gives the tester a lot of information to help diagnose the test  
failure. I don't know that I can gather that kind of information,  
though.

>> Okay. I'll have to see what I can do with SQLERRM then. But isn't it
>> localized?
>
> Yeah, it is.  You don't really want code looking at that to decide  
> what
> to do, if you can possibly avoid it.  It's intended for human  
> consumption.

As I thought, thanks.

Best,

David