Making pgsql error messages more developers' friendly.

Rajesh Kumar Mallah <mallah@trade-india.com> writes:

Shudnt' messages like
ERROR: value too long for type character varying(5)
Indicate which column and table the server is talking about .

Send a patch ;-)

This is not that easy to do: the code that implements the constraint
does not know what it is being applied to. In the general case it
cannot know, because there may be no specific table/column it's being
applied to --- consider "SELECT 'foobar'::char(5)". But if you have
an idea how to give a more-specific error message when possible,
let's see some code.

(Possible plan: the recently-added error context mechanism might
be able to do something for this...)

regards, tom lane

On Fri, 27 Jun 2003, Rajesh Kumar Mallah wrote:

...
similarly when uniq indexes are violated we do not know which
key is causing it.

MySQL is better in these small things.

I think in 7.4dev fkey violation are reported better,
cant such behaviours be extened to other kind of
exceptions?

I was just looking at that fkey violation message yesterday and thinking how
much better it would be to be able to see the offending value in the
message. Is that what 7.4 shows?

--
Nigel J. Andrews

On Friday 27 Jun 2003 12:14 pm, Tom Lane wrote:

Rajesh Kumar Mallah <mallah@trade-india.com> writes:

Shudnt' messages like
ERROR: value too long for type character varying(5)
Indicate which column and table the server is talking about .

Send a patch ;-)

I wish i could ;-)

This is not that easy to do: the code that implements the constraint
does not know what it is being applied to. In the general case it
cannot know, because there may be no specific table/column it's being
applied to --- consider "SELECT 'foobar'::char(5)". But if you have
an idea how to give a more-specific error message when possible,
let's see some code.

(Possible plan: the recently-added error context mechanism might
be able to do something for this...)

Thanks for explaining.
PostgreSQL already exceeds our expectations in the things
which really matters.

regards, tom lane

--
Rajesh Kumar Mallah,
Project Manager (Development)
Infocom Network Limited, New Delhi
phone: +91(11)6152172 (221) (L) ,9811255597 (M)

Visit http://www.trade-india.com ,
India's Leading B2B eMarketplace.

"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:

I was just looking at that fkey violation message yesterday and thinking how
much better it would be to be able to see the offending value in the
message. Is that what 7.4 shows?

You mean like this?

regression=# create table t1 (f1 int primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index 't1_pkey' for table 't1'
CREATE TABLE
regression=# create table t2 (f2 int references t1);
NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY check(s)
CREATE TABLE
regression=# insert into t2 values(42);
ERROR: $1 referential integrity violation - key (f2)=(42) referenced from t2 not found in t1
regression=#

I'm still wondering how to rephrase this to fit in the
recently-agreed-to message style guidelines. I think the
(col names)=(values) part must go into errdetail, but I'm
fuzzy beyond that. Comments?

regards, tom lane

Rajesh Kumar Mallah wrote:

Hi Folks,

Shudnt' messages like

ERROR: value too long for type character varying(5)

Maybe, yes. It's just not that trivial to do.

MySQL is better in these small things.

I think in 7.4dev fkey violation are reported better,
cant such behaviours be extened to other kind of
exceptions?

We are working on it. But pointing to MySQL doesn't help a bit. If you
like MySQL better, then use MySQL instead and don't bother with the side
effects from the data type abstraction you actually bumped into.

Sorry, I'm a bit tired of "MySQL does this ...", "MySQL is better here
..." and so on and so forth. No however good error message system can be
used by the application programmer as replacement for input data
validation. Type checking, foreign keys, check constraints, they all are
last lines of defense, so that a bug in the application or a missing
input validation doesn't cause greater damage. But they are not a
replacement.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

What about development time ? It is always nice to have the database
give you some actually useful pointers instead of making you loose your
time chasing around the error in your code. We are all just humans, do
mistakes, and do like when the mistake is easily spotted by an error
message pointing to the right place.
So the rationale of the request is legitimate.
Your repulsion against comparisons with other databases might be
understandable, but it's the best reference language for non-developer
postgres users to describe the requested feature in terms of the feature
of another database.

Cheers,
Csaba.

On Friday 27 Jun 2003 12:51 pm, Tom Lane wrote:

"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:

I was just looking at that fkey violation message yesterday and thinking
how much better it would be to be able to see the offending value in the
message. Is that what 7.4 shows?

You mean like this?

regression=# create table t1 (f1 int primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index 't1_pkey'
for table 't1' CREATE TABLE
regression=# create table t2 (f2 int references t1);
NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY
check(s) CREATE TABLE
regression=# insert into t2 values(42);
ERROR: $1 referential integrity violation - key (f2)=(42) referenced from
t2 not found in t1 regression=#

I'm still wondering how to rephrase this to fit in the
recently-agreed-to message style guidelines. I think the
(col names)=(values) part must go into errdetail, but I'm
fuzzy beyond that. Comments?

Even this message would be a great relief.
not in a position to comment I will install 7.4dev soon
and use it to find the improvements.

Regds
Mallah.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

--
Rajesh Kumar Mallah,
Project Manager (Development)
Infocom Network Limited, New Delhi
phone: +91(11)6152172 (221) (L) ,9811255597 (M)

Visit http://www.trade-india.com ,
India's Leading B2B eMarketplace.

On Saturday 28 Jun 2003 8:50 pm, Jan Wieck wrote:

Rajesh Kumar Mallah wrote:

Hi Folks,

Shudnt' messages like

ERROR: value too long for type character varying(5)

Maybe, yes. It's just not that trivial to do.

MySQL is better in these small things.

I think in 7.4dev fkey violation are reported better,
cant such behaviours be extened to other kind of
exceptions?

We are working on it.

But pointing to MySQL doesn't help a bit. If you
like MySQL better, then use MySQL instead

I am not a MySQL fan. I have been been using PostgreSQL since
7.0.3 version. Posting it here becoz its a public forum and u made
an attempt to paint me worng here ;-)

Regds
Mallah.

and don't bother with the side
effects from the data type abstraction you actually bumped into.

Sorry, I'm a bit tired of "MySQL does this ...", "MySQL is better here
..." and so on and so forth. No however good error message system can be
used by the application programmer as replacement for input data
validation. Type checking, foreign keys, check constraints, they all are
last lines of defense, so that a bug in the application or a missing
input validation doesn't cause greater damage. But they are not a
replacement.

Jan

--
Rajesh Kumar Mallah,
Project Manager (Development)
Infocom Network Limited, New Delhi
phone: +91(11)6152172 (221) (L) ,9811255597 (M)

Visit http://www.trade-india.com ,
India's Leading B2B eMarketplace.

Rajesh Kumar Mallah wrote:

On Saturday 28 Jun 2003 8:50 pm, Jan Wieck wrote:

Rajesh Kumar Mallah wrote:

Hi Folks,

Shudnt' messages like

ERROR: value too long for type character varying(5)

Maybe, yes. It's just not that trivial to do.

MySQL is better in these small things.

I think in 7.4dev fkey violation are reported better,
cant such behaviours be extened to other kind of
exceptions?

We are working on it.

But pointing to MySQL doesn't help a bit. If you
like MySQL better, then use MySQL instead

I am not a MySQL fan. I have been been using PostgreSQL since
7.0.3 version. Posting it here becoz its a public forum and u made
an attempt to paint me worng here ;-)

Sorry for the misunderstanding, it wasn't meant as an attempt to paint
anything. You are very welcome to help us improving PostgreSQL.

But if you're not, why do you mention MySQL at all this way then? What
was the exact purpose for including this statement?

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Csaba Nagy wrote:

What about development time ? It is always nice to have the database
give you some actually useful pointers instead of making you loose your
time chasing around the error in your code. We are all just humans, do
mistakes, and do like when the mistake is easily spotted by an error
message pointing to the right place.
So the rationale of the request is legitimate.

I never claimed that the request itself wasn't legitimate. And I totally
agree with you up to here.

Your repulsion against comparisons with other databases might be
understandable, but it's the best reference language for non-developer
postgres users to describe the requested feature in terms of the feature
of another database.

You think that the original statement "MySQL is better in these small
things" was an attempt to "describe the requested feature" ... really?

Guess I need to learn some non-developer english someday. Seems to be a
completely different language.

Jan

Cheers,
Csaba.

On Sat, 2003-06-28 at 17:20, Jan Wieck wrote:

Rajesh Kumar Mallah wrote:

Hi Folks,

Shudnt' messages like

ERROR: value too long for type character varying(5)

Maybe, yes. It's just not that trivial to do.

MySQL is better in these small things.

I think in 7.4dev fkey violation are reported better,
cant such behaviours be extened to other kind of
exceptions?

We are working on it. But pointing to MySQL doesn't help a bit. If you
like MySQL better, then use MySQL instead and don't bother with the side
effects from the data type abstraction you actually bumped into.

Sorry, I'm a bit tired of "MySQL does this ...", "MySQL is better here
..." and so on and so forth. No however good error message system can be
used by the application programmer as replacement for input data
validation. Type checking, foreign keys, check constraints, they all are
last lines of defense, so that a bug in the application or a missing
input validation doesn't cause greater damage. But they are not a
replacement.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

LOL !

You take it too seriously.
But yes, users (i.e. non-developers of a product) speak a different
language I guess.

"This and that DB is better because it implements this and that feature
and you don't !!!"

would translate to:

"It would be very nice if your fine DB product would support this and
that feature because we discovered that it's very useful (or just plain
convenient) while using that other DB, which we would like to change
with yours, but little things like this prevent us"

All depends on interpretation. But the bottom line is that a product
will most likely improve beyond the usage of it's own developers if it
responds to user criticisms.

Cheers,
Csaba.

On Monday 30 Jun 2003 6:32 pm, Jan Wieck wrote:

Rajesh Kumar Mallah wrote:

On Saturday 28 Jun 2003 8:50 pm, Jan Wieck wrote:

Rajesh Kumar Mallah wrote:

Hi Folks,

Shudnt' messages like

ERROR: value too long for type character varying(5)

Maybe, yes. It's just not that trivial to do.

MySQL is better in these small things.

I think in 7.4dev fkey violation are reported better,
cant such behaviours be extened to other kind of
exceptions?

We are working on it.

But pointing to MySQL doesn't help a bit. If you
like MySQL better, then use MySQL instead

I am not a MySQL fan. I have been been using PostgreSQL since
7.0.3 version. Posting it here becoz its a public forum and u made
an attempt to paint me worng here ;-)

Sorry for the misunderstanding, it wasn't meant as an attempt to paint
anything. You are very welcome to help us improving PostgreSQL.

But if you're not, why do you mention MySQL at all this way then? What
was the exact purpose for including this statement?

LOL
please do not take it too seriously and i apologize
if the original post was offending.

I mentioned MySQL becoz before PostgreSQL i was a MySQL user.
If i were an Oracle user i would have mentioned that only..
MySQL and PostgreSQL are the only databases i have
used so far so i can reference MySQL only .

Mallah.

Jan

--
Rajesh Kumar Mallah,
Project Manager (Development)
Infocom Network Limited, New Delhi
phone: +91(11)6152172 (221) (L) ,9811255597 (M)

Visit http://www.trade-india.com ,
India's Leading B2B eMarketplace.