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 13
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
> mes
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 d
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-chara
-*- 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
> > param
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
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
"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 ma
> 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
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 ov
> 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
> 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 denomina
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
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
--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 spellin
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 NUL
--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 value
17 matches
Mail list logo