]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. But I guess
a case could be made for ERRCODE_DATATYPE_MISMATCH there. I
definitely
do not agree with your suggestion of ERRCODE_TOO_MANY_COLUMNS ---
that's
from Program Limit Exceeded category which is 100% the wrong thing.
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 distinct from the
column data type error.
And I'm going on SQLSTATE here because I'm doing exception handling in
pl/PgSQL and want to handle the two errors differently.
The other errors are coming from within record_eq(), where what it's
got is two composite values that don't match as to structure. It
seems fairly clear that DATATYPE_MISMATCH is the right thing there.
I see, it's thinking of the two row objects as distinct types, rather
than complaining about different numbers of columns.
So if we feel that these errors should match, I'd vote for changing to
DATATYPE_MISMATCH, not changing to SYNTAX_ERROR. But I'm not entirely
convinced that there's a reason to make them match. I'm not sure that
they really have the same cause when you look at it concretely.
Okay. I'll have to see what I can do with SQLERRM then. But isn't it
localized?
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
