Обсуждение: Making pgsql error messages more developers' friendly.
Hi Folks, Shudnt' messages like ERROR: value too long for type character varying(5) Indicate which column and table the server is talking about . Without that we need to open the application source code, find the SQL, then describe the table to find which column is varchar(5) and if there is two columns of varchar(5) we keep wondering. 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? Regds Mallah. -- 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 <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 #
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.
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 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 >
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 Mon, 2003-06-30 at 15:30, Jan Wieck wrote: > 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 # >
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.