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