Oh, removed.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have added this email to CVS as src/tools/error_text. Any changes to
> > it?
>
> Waste of CVS space; the real documentation is in SGML:
> h
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have added this email to CVS as src/tools/error_text. Any changes to
> it?
Waste of CVS space; the real documentation is in SGML:
http://developer.postgresql.org/docs/postgres/error-style-guide.html
regards, tom lane
I have added this email to CVS as src/tools/error_text. Any changes to
it?
---
Tom Lane wrote:
> I'm about to start going through the backend's elog() calls to update
> them to ereport() style, add error code numbers, polis
Tom Lane wrote:
> > It was mostly meant as a broad hint not to write "open() failed", which
> > can clearly be written more user-friendly without loss of information.
> > For less obvious cases we can use a mixed style. Say 'could not
> > synchronize file "%s" with disk (fsync failed)'. That tells
On Fri, 14 Mar 2003, Steve Crawford wrote:
> One thing that would be great from a user's perspective (and which might
> reduce the volume of support questions as well) is to uniquely number all
> errors as in:
> Error 1036: the foo could not faz the fleep
>
I agree with the unique codes.
It does
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I would prefer leaving the formatting to client and have the backend
> provide a more semantic-type "markup". For example the newline character
> could be considered a paragraph break and within the paragraph the text
> just flows. (We could hack up
Tom Lane writes:
> I think a style guide should just say "Keep primary messages short".
Right.
> How about something like "Avoid tabs. Insert newlines as needed to keep
> message lines shorter than X characters. Keep in mind that client
> code might reformat long messages for its own purposes,
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Some people were mentioning an error message style guide. Here's a start
> of one that I put together a while ago. Feel free to consider it.
Looks like a good start. But you expected quibbles, right? ;-)
> The main part of a message should be at
One thing that would be great from a user's perspective (and which might
reduce the volume of support questions as well) is to uniquely number all
errors as in:
Error 1036: the foo could not faz the fleep
The advantages of this include:
Ease of documentation: a manual could containg a section di
Some people were mentioning an error message style guide. Here's a start
of one that I put together a while ago. Feel free to consider it.
Size of message
---
The main part of a message should be at most 72 characters long. For
embedded format specifiers (%s, %d, etc.), a reasonab
10 matches
Mail list logo
