Re: [HACKERS] Upgrading the backend's error-message infrastructure

2003-03-14 Thread Darko Prenosil
On Thursday 13 March 2003 20:51, Tom Lane wrote: (Or, protocol upgrade phase 1...) After digging through our many past discussions of what to do with error messages, I have put together the following first-cut proposal. Fire at will... Objective - The basic objective here is to

Re: [HACKERS] Upgrading the backend's error-message infrastructure

2003-03-14 Thread Tom Lane
Darko Prenosil [EMAIL PROTECTED] writes: What about user messages ? If I remember correct, MSSQL had a system catalog table with formated error messages, and it was possible to raise error with error number and it's parameters. It can be very useful when you must raise same error from

Re: [HACKERS] Upgrading the backend's error-message infrastructure

2003-03-14 Thread Þórhallur Hálfdánarson
-*- Tom Lane [EMAIL PROTECTED] [ 2003-03-14 15:33 ]: Darko Prenosil [EMAIL PROTECTED] writes: What about user messages ? If I remember correct, MSSQL had a system catalog table with formated error messages, and it was possible to raise error with error number and it's parameters. It

Re: [HACKERS] Upgrading the backend's error-message infrastructure

2003-03-14 Thread johnnnnnn
On Thu, Mar 13, 2003 at 03:51:00PM -0500, Tom Lane wrote: Wire-protocol changes - Error and Notice (maybe also Notify?) msgs will have this structure: E x string \0 x string \0 x string \0 \0 where the x's are single-character field

Re: [HACKERS] Upgrading the backend's error-message infrastructure

2003-03-14 Thread Tom Lane
johnn [EMAIL PROTECTED] writes: It would seem to make more sense to me to provide a different function(s) which allows the lookup Messages, Details, and Hints based on the SQLSTATE. This would constrain us to have a different SQLSTATE for every error message, which we aren't going to do.

Re: [HACKERS] Upgrading the backend's error-message infrastructure

2003-03-14 Thread johnnnnnn
On Fri, Mar 14, 2003 at 12:23:04PM -0500, Tom Lane wrote: It would seem to make more sense to me to provide a different function(s) which allows the lookup Messages, Details, and Hints based on the SQLSTATE. This would constrain us to have a different SQLSTATE for every error message,

Re: [HACKERS] Upgrading the backend's error-message infrastructure

2003-03-14 Thread Tom Lane
johnn [EMAIL PROTECTED] writes: If it's different enough to warrant a different message, then, in my mind, it's different enough to warrant a different SQLSTATE. Unfortunately, you're at odds with the SQL spec authors, who have made their intentions pretty clear by defining only about 130

[HACKERS] Upgrading the backend's error-message infrastructure

2003-03-13 Thread Tom Lane
(Or, protocol upgrade phase 1...) After digging through our many past discussions of what to do with error messages, I have put together the following first-cut proposal. Fire at will... Objective - The basic objective here is to divide error reports into multiple fields, and in

Re: [HACKERS] Upgrading the backend's error-message infrastructure

2003-03-13 Thread Neil Conway
On Thu, 2003-03-13 at 15:51, Tom Lane wrote: After digging through our many past discussions of what to do with error messages, I have put together the following first-cut proposal. Great work, Tom! While we're effectively changing every elog call site in the backend, would it also be a good

Re: [HACKERS] Upgrading the backend's error-message infrastructure

2003-03-13 Thread Tom Lane
Neil Conway [EMAIL PROTECTED] writes: While we're effectively changing every elog call site in the backend, would it also be a good idea to adopt a standard for the format of error messages? (e.g. capitalization, grammar, etc.) Yup. I was planning to bring that up as a separate thread. I

Re: [HACKERS] Upgrading the backend's error-message infrastructure

2003-03-13 Thread Christopher Kings-Lynne
Comments? All the error stuff sounds really neat. I volunteer for doing lots of elog changes when the time comes. Would it be possible to do a command line app? bash$ pg_error 1200D Severity: ERROR Message: Division by zero Detail: Hint: Modify statement to prevent zeros appearing in

Re: [HACKERS] Upgrading the backend's error-message infrastructure

2003-03-13 Thread Christopher Kings-Lynne
Great work, Tom! While we're effectively changing every elog call site in the backend, would it also be a good idea to adopt a standard for the format of error messages? (e.g. capitalization, grammar, etc.) I 100% agree with this - a style guide! Chris ---(end of

Re: [HACKERS] Upgrading the backend's error-message infrastructure

2003-03-13 Thread Neil Conway
On Thu, 2003-03-13 at 21:16, Christopher Kings-Lynne wrote: Would it be possible to do a command line app? bash$ pg_error 1200D Severity: ERROR Message: Division by zero Detail: Hint: Modify statement to prevent zeros appearing in denominators. Is there any benefit to having this over

Re: [HACKERS] Upgrading the backend's error-message infrastructure

2003-03-13 Thread Christopher Kings-Lynne
On Thu, 2003-03-13 at 21:16, Christopher Kings-Lynne wrote: Would it be possible to do a command line app? bash$ pg_error 1200D Severity: ERROR Message: Division by zero Detail: Hint: Modify statement to prevent zeros appearing in denominators. Is there any benefit to having this

Re: [HACKERS] Upgrading the backend's error-message infrastructure

2003-03-13 Thread Tom Lane
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Would it be possible to do a command line app? bash$ pg_error 1200D Severity: ERROR Message: Division by zero Detail: Hint: Modify statement to prevent zeros appearing in denominators. You're assuming that there's a one-to-one mapping of

Re: [HACKERS] Upgrading the backend's error-message infrastructure

2003-03-13 Thread Larry Rosenman
--On Thursday, March 13, 2003 15:51:00 -0500 Tom Lane [EMAIL PROTECTED] wrote: (__FUNCTION__ is only used if we are compiling in gcc). errstart() pushes an empty entry onto an error-data-collection stack and fills in the behind-the-scenes file/line entries. errmsg() and friends stash values

Re: [HACKERS] Upgrading the backend's error-message infrastructure

2003-03-13 Thread Tom Lane
Larry Rosenman [EMAIL PROTECTED] writes: __FUNCTION__ or an equivalent is MANDATED by C99, and available on UnixWare's native cc. You might want to make a configure test for it. Right, __func__ is the C99 spelling. I did have a configure test in mind here: __func__ or __FUNCTION__ or NULL is

Re: [HACKERS] Upgrading the backend's error-message infrastructure

2003-03-13 Thread Larry Rosenman
--On Thursday, March 13, 2003 16:20:21 -0500 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: __FUNCTION__ or an equivalent is MANDATED by C99, and available on UnixWare's native cc. You might want to make a configure test for it. Right, __func__ is the C99 spelling.