On Tue, Jun 30, 2009 at 03:16:09PM -0700, David Wheeler wrote:
> On Jun 30, 2009, at 3:05 PM, David Fetter wrote:
>
Would this be the first C piece? If not, it might be worth
doing.
>>>
>>> I don't understand the question.
>>
>> I was thinking of this as part of PgTAP.
>
> Oh. There is
On Jun 30, 2009, at 3:05 PM, David Fetter wrote:
Would this be the first C piece? If not, it might be worth doing.
I don't understand the question.
I was thinking of this as part of PgTAP.
Oh. There is a piece of C, but it's just an implementation of
pg_typeof() so that pgTAP can use it
On Tue, Jun 30, 2009 at 02:01:26PM -0700, David Wheeler wrote:
> On Jun 30, 2009, at 1:40 PM, David Fetter wrote:
>
>>> Yes, that's my ideal, but Tom says I need to write C code to get that
>>> information from RECORD objects, alas. :-(
>>
>> Would this be the first C piece? If not, it might be wo
On Jun 30, 2009, at 1:40 PM, David Fetter wrote:
Yes, that's my ideal, but Tom says I need to write C code to get that
information from RECORD objects, alas. :-(
Would this be the first C piece? If not, it might be worth doing.
I don't understand the question. But yes, I think it'd be worth
On Tue, Jun 30, 2009 at 01:10:01PM -0700, David Wheeler wrote:
> On Jun 30, 2009, at 11:54 AM, David Fetter wrote:
>
>>># Failed test 148
>>># Number of columns differs between queries
>>># have: 4 columns
>>># want: 3 columns
>>
>> Shouldn't that just read:
>>
>
On Jun 30, 2009, at 11:54 AM, David Fetter wrote:
# Failed test 148
# Number of columns differs between queries
# have: 4 columns
# want: 3 columns
Shouldn't that just read:
have: (int, int, text, point)
want: (int, int, text)
Yes, that's my ideal, but
On Jun 30, 2009, at 11:48 AM, Tom Lane wrote:
Is there a way
to get a RECORD object to tell me what data types it contains?
Not at the SQL level. Of course, if you're writing C, you can do
something similar to what record_eq and friends do.
Pity. I'm trying to keep C out of pgTAP (for the m
On Jun 30, 2009, at 11:46 AM, Tom Lane wrote:
For my results_eq() in pgTAP, it could output different diagnostics.
Well, that's not terribly compelling ;-).
Pllt.
I wouldn't have any big
objection to splitting out ERRCODE_COLUMN_COUNT_MISMATCH as a separate
SQLSTATE for 8.5 and beyond,
On Tue, Jun 30, 2009 at 11:27:20AM -0700, David Wheeler wrote:
> 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
"David E. Wheeler" writes:
> Is there a way
> to get a RECORD object to tell me what data types it contains?
Not at the SQL level. Of course, if you're writing C, you can do
something similar to what record_eq and friends do.
regards, tom lane
--
Sent via pgsql-hacke
"David E. Wheeler" writes:
> On Jun 30, 2009, at 11:18 AM, Tom Lane wrote:
>> What's the argument
>> for needing to handle this differently from DATATYPE_MISMATCH?
> For my results_eq() in pgTAP, it could output different diagnostics.
Well, that's not terribly compelling ;-). I wouldn't have
On Jun 30, 2009, at 11:27 AM, David E. Wheeler wrote:
# 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)
#
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 co
"David E. Wheeler" writes:
> Yeah, that was just an aside. I liked that I got different errors when
> there were different numbers of columns than when the data types of
> the columns disagreed. I'm not sure that SYNTAX ERROR is a great code
> for when the count disagrees, but at least it's
]On Jun 30, 2009, at 11:00 AM, Tom Lane wrote:
Oh, you're complaining about the SQLSTATE not the error text.
I guess that to the extent that any actual thought went into it
(which may not have been much) the reasoning was that you'd have to
change the syntax of your query in order to fix this.
"David E. Wheeler" writes:
> On Jun 30, 2009, at 10:28 AM, Tom Lane wrote:
>> Not for me:
>>
>> regression=# VALUES (1, 2), (3, 4) EXCEPT VALUES (1), (3);
>> ERROR: each EXCEPT query must have the same number of columns
> Turn on verbosity:
> try=# \set VERBOSITY verbose
> try=# VALUES (1, 2),
On Jun 30, 2009, at 10:28 AM, Tom Lane wrote:
VALUES (1, 2), (3, 4) EXCEPT VALUES (1), (3);
Throws 42601 SYNTAX ERROR.
Not for me:
regression=# VALUES (1, 2), (3, 4) EXCEPT VALUES (1), (3);
ERROR: each EXCEPT query must have the same number of columns
Turn on verbosity:
try=# \set
"David E. Wheeler" writes:
> This is what I see. This query:
> VALUES (1, 2), (3, 4) EXCEPT VALUES (1, 'foo'), (3, 'bar');
> Throws 42804 DATATYPE MISMATCH.
Yeah ...
> Meanwhile, this query:
> VALUES (1, 2), (3, 4) EXCEPT VALUES (1), (3);
> Throws 42601 SYNTAX ERROR.
Not for me:
Howdy,
I'm working on functions to compare result sets for pgTAP. In the
process, I found what appears to be an inconsistency in error handling
when comparing incomparable results. I'm testing in 8.4RC2, but the
issue may go back for all I know. Perhaps it's intentional?
This is what I se
19 matches
Mail list logo
