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