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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
