Re: [GENERAL] Making pgsql error messages more developers' friendly.
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. # #== [EMAIL PROTECTED] # ---(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. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Making pgsql error messages more developers' friendly.
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. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Making pgsql error messages more developers' friendly.
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. # > #== [EMAIL PROTECTED] # > > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Making pgsql error messages more developers' friendly.
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. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Making pgsql error messages more developers' friendly.
On Friday 27 Jun 2003 12:51 pm, Tom Lane wrote: > "Nigel J. Andrews" <[EMAIL PROTECTED]> 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. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Making pgsql error messages more developers' friendly.
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. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Making pgsql error messages more developers' friendly.
"Nigel J. Andrews" <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] Making pgsql error messages more developers' friendly.
On Friday 27 Jun 2003 12:14 pm, Tom Lane wrote: > Rajesh Kumar Mallah <[EMAIL PROTECTED]> 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. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] Making pgsql error messages more developers' friendly.
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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Making pgsql error messages more developers' friendly.
Rajesh Kumar Mallah <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[GENERAL] 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. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
