Skip site navigation (1) Skip section navigation (2)

Re: Inconsistent Errors on Row Comparisons

From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Inconsistent Errors on Row Comparisons
Date: 2009-06-30 18:27:20
Message-ID: 381EB7AA-20A3-4994-A90D-151E270618E5@kineticode.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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


In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2009-06-30 18:31:39
Subject: Re: 8.5 development schedule
Previous:From: Tom LaneDate: 2009-06-30 18:18:02
Subject: Re: Inconsistent Errors on Row Comparisons

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group