+++ /dev/null
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id VAA09681
- for
; Thu, 8 Mar 2001 21:04:12 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f2924Hx38075;
- Thu, 8 Mar 2001 21:04:17 -0500 (EST)
-Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154])
- by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f2920Ex24188
- for
; Thu, 8 Mar 2001 21:00:14 -0500 (EST)-Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
- by sss.pgh.pa.us (8.11.1/8.11.1) with ESMTP id f29209904744
- for
; Thu, 8 Mar 2001 21:00:09 -0500 (EST)-Subject: Re: [HACKERS] Internationalized error messages
- message dated "Thu, 08 Mar 2001 16:42:22 -0800"
-Date: Thu, 08 Mar 2001 21:00:09 -0500
-From: Tom Lane
-Precedence: bulk
-Status: OR
-
-> On Thu, Mar 08, 2001 at 11:49:50PM +0100, Peter Eisentraut wrote:
->> I really feel that translated error messages need to happen soon.
-
-Agreed.
-
-> Similar approaches have been tried frequently, and even enshrined
-> in standards (e.g. POSIX catgets), but have almost always proven too
-> cumbersome. The problem is that keeping programs that interpret the
-> numeric code in sync with the program they monitor is hard, and trying
-> to avoid breaking all those secondary programs hinders development on
-> the primary program. Furthermore, assigning code numbers is a nuisance,
-> and they add uninformative clutter.
-
-There's a difficult tradeoff to make here, but I think we do want to
-distinguish between the "official error code" --- the thing that has
-translations into various languages --- and what the backend is actually
-allowed to print out. It seems to me that a fairly large fraction of
-the unique messages found in the backend can all be lumped under the
-category of "internal error", and that we need to have only one official
-error code and one user-level translated message for the lot of them.
-But we do want to be able to print out different detail messages for
-each of those internal errors. There are other categories that might be
-lumped together, but that one alone is sufficiently large to force us
-to recognize it. This suggests a distinction between a "primary" or
-"user-level" error message, which we catalog and provide translations
-for, and a "secondary", "detail", or "wizard-level" error message that
-exists only in the backend source code, and only in English, and so
-can be made up on the spur of the moment.
-
-Another thing that's bothered me for a long time is our inconsistent
-approach to determining where in the code a message comes from. A lot
-of the messages currently embed the name of the generating routine right
-into the error text. Again, we ought to separate the functionality:
-the source-code location is valuable but ought not form part of the
-primary error message. I would like to see elog() become a macro that
-invokes __FILE__ and __LINE__ to automatically make the *exact* source
-code location become part of the secondary error information, and then
-drop the convention of using the routine name in the message text.
-
-Something else we have talked about off-and-on is providing locator
-information for errors that can be associated with a particular point in
-the query string (lexical and syntactic errors). This would probably be
-best returned as a character index.
-
-Another thing that I missed in Peter's proposal is how we are going to
-cope with messages that include parameters. Surely we do not expect
-gettext to start with 'Attribute "foo" not found' and distinguish fixed
-from variable parts of that string?
-
-So it's clear that we need to devise a way of breaking an "error
-message" into multiple portions, including:
-
- Primary error message (localizable)
- Parameters to insert into error message (user identifiers, etc)
- Secondary (wizard) error message (optional)
- Source code location
- Query text location (optional)
-
-and perhaps others that I have forgotten about. One of the key things
-to think about is whether we can, or should try to, transmit all this
-stuff in a backwards-compatible protocol. That would mean we'd have
-to dump all the info into a single string, which is doable but would
-perhaps look pretty ugly:
-
- ERROR: Attribute "foo" not found -- basic message for dumb frontends
- ERRORCODE: UNREC_IDENT -- key for finding localized message
- PARAM1: foo -- something to embed in the localized message
- MESSAGE: Attribute or table name not known within context of query
- CODELOC: src/backend/parser/parse_clause.c line 345
- QUERYLOC: 22
-
-Alternatively we could suppress most of this stuff unless the frontend
-specifically asks for it (and presumably is willing to digest it for
-the user).
-
-Bottom line for me is that if we are going to go to the trouble of
-examining and changing every single elog() in the system, we should
-try to get all of these issues cleaned up at once. Let's not have to
-go back and do it again later.
-
- regards, tom lane
-
----------------------------(end of broadcast)---------------------------
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id WAA14437
- for
; Thu, 8 Mar 2001 22:35:36 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f293Zhx83174;
- Thu, 8 Mar 2001 22:35:43 -0500 (EST)
-Received: from store.d.zembu.com (nat.zembu.com [209.128.96.253])
- by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f293Ulx76439
- for
; Thu, 8 Mar 2001 22:30:47 -0500 (EST)-Received: by store.d.zembu.com (Postfix, from userid 509)
- id C6F2BA75B; Thu, 8 Mar 2001 19:30:41 -0800 (PST)
-Date: Thu, 8 Mar 2001 19:30:41 -0800
-Subject: Re: [HACKERS] Internationalized error messages
-Mime-Version: 1.0
-Content-Type: text/plain; charset=us-ascii
-Content-Disposition: inline
-User-Agent: Mutt/1.2.5i
-Precedence: bulk
-Status: OR
-
-On Thu, Mar 08, 2001 at 09:00:09PM -0500, Tom Lane wrote:
-> > Similar approaches have been tried frequently, and even enshrined
-> > in standards (e.g. POSIX catgets), but have almost always proven too
-> > cumbersome. The problem is that keeping programs that interpret the
-> > numeric code in sync with the program they monitor is hard, and trying
-> > to avoid breaking all those secondary programs hinders development on
-> > the primary program. Furthermore, assigning code numbers is a nuisance,
-> > and they add uninformative clutter.
->
-> There's a difficult tradeoff to make here, but I think we do want to
-> distinguish between the "official error code" --- the thing that has
-> translations into various languages --- and what the backend is actually
-> allowed to print out. It seems to me that a fairly large fraction of
-> the unique messages found in the backend can all be lumped under the
-> category of "internal error", and that we need to have only one official
-> error code and one user-level translated message for the lot of them.
-> But we do want to be able to print out different detail messages for
-> each of those internal errors. There are other categories that might be
-> lumped together, but that one alone is sufficiently large to force us
-> to recognize it. This suggests a distinction between a "primary" or
-> "user-level" error message, which we catalog and provide translations
-> for, and a "secondary", "detail", or "wizard-level" error message that
-> exists only in the backend source code, and only in English, and so
-> can be made up on the spur of the moment.
-
-I suggest using different named functions/macros for different
-categories of message, rather than arguments to a common function.
-(I.e. "elog(ERROR, ...)" Considered Harmful.)
-
-You might even have more than one call at a site, one for the official
-message and another for unofficial or unstable informative details.
-
-> Another thing that I missed in Peter's proposal is how we are going to
-> cope with messages that include parameters. Surely we do not expect
-> gettext to start with 'Attribute "foo" not found' and distinguish fixed
-> from variable parts of that string?
-
-The common way to deal with this is to catalog the format string itself,
-with its embedded % directives. The tricky bit, and what the printf
-family has had to be extended to handle, is that the order of the formal
-arguments varies with the target language. The original string is an
-ordinary printf string, but the translations may have to refer to the
-substitution arguments by numeric position (as well as type).
-
-There is probably Free code to implement that.
-
-As much as possible, any compile-time annotations should be extracted
-into the catalog and filtered out of the source, to be reunited only
-when you retrieve the catalog entry.
-
-
-> So it's clear that we need to devise a way of breaking an "error
-> message" into multiple portions, including:
->
-> Primary error message (localizable)
-> Parameters to insert into error message (user identifiers, etc)
-> Secondary (wizard) error message (optional)
-> Source code location
-> Query text location (optional)
->
-> and perhaps others that I have forgotten about. One of the key things
-> to think about is whether we can, or should try to, transmit all this
-> stuff in a backwards-compatible protocol. That would mean we'd have
-> to dump all the info into a single string, which is doable but would
-> perhaps look pretty ugly:
->
-> ERROR: Attribute "foo" not found -- basic message for dumb frontends
-> ERRORCODE: UNREC_IDENT -- key for finding localized message
-> PARAM1: foo -- something to embed in the localized message
-> MESSAGE: Attribute or table name not known within context of query
-> CODELOC: src/backend/parser/parse_clause.c line 345
-> QUERYLOC: 22
-
-Whitespace can be used effectively. E.g. only primary messages appear
-in column 0. PG might emit this, which is easily filtered:
-
- Attribute "foo" not found
- severity: cannot proceed
- explain: An attribute or table was name not known within
- explain: the context of the query.
- index: 237 Attribute \"%s\" not found
- location: src/backend/parser/parse_clause.c line 345
- query_position: 22
-
-Here the first line is the localized replacement of what appears in the
-code, with arguments substituted in. The other stuff comes from the
-catalog
-
-The call looks like
-
- elog_query("Attribute \"%s\" not found", foo);
- elog_explain("An attribute or table was name not known within"
- "the context of the query.");
- elog_severity(ERROR);
-
-which might gets expanded (squeezed) by the preprocessor to
-
- _elog(current_query_position, "Attribute \"%s\" not found", foo);
-
-while a separate tool scans the sources and builds the catalog,
-annotating it with severity, line number, etc. Human translators
-may edit copies of the resulting catalog. The call to _elog looks up
-the string in the catalog, substitutes arguments into the translation,
-and emits it along with the catalog index number and whatever else
-has been requested in the config file. Alternatively, any other program
-can use the number to pull the annotations out of the catalog given
-just the index.
-
-> Alternatively we could suppress most of this stuff unless the frontend
-> specifically asks for it (and presumably is willing to digest it for
-> the user).
->
-> Bottom line for me is that if we are going to go to the trouble of
-> examining and changing every single elog() in the system, we should
-> try to get all of these issues cleaned up at once. Let's not have to
-> go back and do it again later.
-
-The more complex it is, the more likely that will need to be redone.
-The simpler the calls look, the more likely that you can automate
-(or implement invisibly) any later improvements.
-
-Nathan Myers
-
----------------------------(end of broadcast)---------------------------
-TIP 5: Have you checked our extensive FAQ?
-
-http://www.postgresql.org/users-lounge/docs/faq.html
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id AAA25061
- for
; Fri, 9 Mar 2001 00:41:08 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f295f9x37185;
- Fri, 9 Mar 2001 00:41:09 -0500 (EST)
-Received: from technoart.net ([212.17.18.2])
- by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f295a9x17382
- for
; Fri, 9 Mar 2001 00:36:09 -0500 (EST)-Received: from dyp.perchine.com ([212.17.18.66])
- by technoart.net (8.8.8/8.8.8) with SMTP id LAA22076
- for
; Fri, 9 Mar 2001 11:36:07 +0600-Content-Type: text/plain;
- charset="koi8-r"
-From: Denis Perchine
-Subject: Re: [HACKERS] Internationalized error messages
-Date: Fri, 9 Mar 2001 11:34:42 +0600
-X-Mailer: KMail [version 1.2.1]
-In-Reply-To:
-MIME-Version: 1.0
-Content-Transfer-Encoding: 8bit
-Precedence: bulk
-Status: OR
-
-> I like this approach. One of the nice things about Oracle is that
-> they have an error manual. All Oracle errors have an associated
-> number. You can look up that number in the error manual to find a
-> paragraph giving details and workarounds. Admittedly, sometimes the
-> further details are not helpful, but sometimes they are. The basic
-> idea of being able to look up an error lets programmers balance the
-> need for a terse error message with the need for a fuller explanation.
-
-One of the examples when you need exact error message code is when you want
-to separate unique index violations from other errors. This often needed when
-you want just do insert, and leave all constraint checking to database...
-
---
-Sincerely Yours,
-Denis Perchine
-
-----------------------------------
-HomePage: http://www.perchine.com/dyp/
-FidoNet: 2:5000/120.5
-----------------------------------
-
----------------------------(end of broadcast)---------------------------
-TIP 6: Have you searched our list archives?
-
-http://www.postgresql.org/search.mpl
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id GAA06293
- for
; Fri, 9 Mar 2001 06:30:04 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f29BTvx46311;
- Fri, 9 Mar 2001 06:29:57 -0500 (EST)
-Received: from ara.zf.jcu.cz (ara.zf.jcu.cz [160.217.161.4])
- by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f29Agpx33552
- for
; Fri, 9 Mar 2001 05:43:10 -0500 (EST)-Received: (from zakkr@localhost)
- by ara.zf.jcu.cz (8.9.3/8.9.3/Debian 8.9.3-21) id IAA09255;
- Fri, 9 Mar 2001 08:53:20 +0100
-Date: Fri, 9 Mar 2001 08:53:20 +0100
-From: Karel Zak
-To: Tom Lane
-Subject: Re: [HACKERS] Internationalized error messages
-Mime-Version: 1.0
-Content-Type: text/plain; charset=us-ascii
-User-Agent: Mutt/1.0.1i
-Precedence: bulk
-Status: OR
-
-On Thu, Mar 08, 2001 at 09:00:09PM -0500, Tom Lane wrote:
-> > On Thu, Mar 08, 2001 at 11:49:50PM +0100, Peter Eisentraut wrote:
-> >> I really feel that translated error messages need to happen soon.
->
-> Agreed.
-
- Yes, error codes is *very* wanted feature.
-
->
-> ERROR: Attribute "foo" not found -- basic message for dumb frontends
-> ERRORCODE: UNREC_IDENT -- key for finding localized message
-> PARAM1: foo -- something to embed in the localized message
-> MESSAGE: Attribute or table name not known within context of query
-> CODELOC: src/backend/parser/parse_clause.c line 345
-> QUERYLOC: 22
-
- Great idea! I agree that we need some powerful Error protocol instead
-currect string based messages.
-
- For transaltion to other languages I not sure with gettext() stuff on
-backend -- IMHO better (faster) solution will postgres system catalog
-with it.
-
- May be add new command too: SET MESSAGE_LANGUAGE TO , because
-wanted language not must be always same as locale setting.
-
- Something like elog(ERROR, gettext(...)); is usable, but not sounds good
-for me.
-
- Karel
-
---
- Karel Zak
- http://home.zf.jcu.cz/~zakkr/
-
- C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
-
----------------------------(end of broadcast)---------------------------
-TIP 5: Have you checked our extensive FAQ?
-
-http://www.postgresql.org/users-lounge/docs/faq.html
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id GAA10006
- for
; Fri, 9 Mar 2001 06:43:47 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f29Bhnx49065;
- Fri, 9 Mar 2001 06:43:49 -0500 (EST)
-Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
- by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f29Bgpx48712
- for
; Fri, 9 Mar 2001 06:42:53 -0500 (EST)-Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
- by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id UAA07670
- for
; Fri, 9 Mar 2001 20:42:46 +0900 (JST)-Received: from localhost (IDENT:t-ishii@portsv3-8 [133.137.84.8])
- by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id UAA22314;
- Fri, 9 Mar 2001 20:42:43 +0900
-Subject: Re: [HACKERS] Internationalized error messages
-X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1
- =?iso-2022-jp?B?KBskQjAqGyhCKQ==?=
-Mime-Version: 1.0
-Content-Type: Text/Plain; charset=us-ascii
-Content-Transfer-Encoding: 7bit
-Date: Fri, 09 Mar 2001 20:42:26 +0900
-From: Tatsuo Ishii
-X-Dispatcher: imput version 20000228(IM140)
-Lines: 17
-Precedence: bulk
-Status: OR
-
-> For transaltion to other languages I not sure with gettext() stuff on
-> backend -- IMHO better (faster) solution will postgres system catalog
-> with it.
->
-> May be add new command too: SET MESSAGE_LANGUAGE TO , because
-> wanted language not must be always same as locale setting.
-
-In the multibyte enabled environment, that kind of command would not
-be necessary except UNICODE and MULE_INTERNAL, since they are
-multi-lingual encoding. For them, we might need something like:
-
-SET LANGUAGE_PREFERENCE TO 'Japanese';
-
-For the long term solutuon, this kind of problem should be solved in
-the implemetaion of SQL-92/99 i18n features.
---
-Tatsuo Ishii
-
----------------------------(end of broadcast)---------------------------
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id KAA22198
- for
; Fri, 9 Mar 2001 10:37:11 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f29FbDx71892;
- Fri, 9 Mar 2001 10:37:13 -0500 (EST)
-Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81])
- by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f29FaXx71776
- for
; Fri, 9 Mar 2001 10:36:33 -0500 (EST)-Received: from fwd01.sul.t-online.com
- by mailout03.sul.t-online.com with smtp
- id 14bOwN-0001Ce-03; Fri, 09 Mar 2001 16:36:27 +0100
-Received: from peter.localdomain (520083510237-0001@[212.185.245.76]) by fmrl01.sul.t-online.com
- with esmtp id 14bOw7-0yVrI8C; Fri, 9 Mar 2001 16:36:11 +0100
-Date: Fri, 9 Mar 2001 16:45:54 +0100 (CET)
-Subject: Re: [HACKERS] Internationalized error messages
-MIME-Version: 1.0
-Content-Type: TEXT/PLAIN; charset=US-ASCII
-Precedence: bulk
-Status: OR
-
-Nathan Myers writes:
-
-> > elog(ERROR, "XYZ01", gettext("stuff happened"));
->
-> Similar approaches have been tried frequently, and even enshrined
-> in standards (e.g. POSIX catgets), but have almost always proven too
-> cumbersome. The problem is that keeping programs that interpret the
-> numeric code in sync with the program they monitor is hard, and trying
-> to avoid breaking all those secondary programs hinders development on
-> the primary program.
-
-That's why no one uses catgets and everyone uses gettext.
-
-> Furthermore, assigning code numbers is a nuisance, and they add
-> uninformative clutter.
-
-The error codes are exactly what we want, to allow client programs (as
-opposed to humans) to identify the errors. The code in my example has
-nothing to do with the message id in the catgets interface.
-
-> It's better to scan the program for elog() arguments, and generate
-> a catalog by using the string itself as the index code. Those
-> maintaining the secondary programs can compare catalogs to see what
-> has been broken by changes and what new messages to expect. elog()
-> itself can (optionally) invent tokens (e.g. catalog indices) to help
-> out those programs.
-
-That's what gettext does for you.
-
---
-
-
----------------------------(end of broadcast)---------------------------
-TIP 3: if posting/reading through Usenet, please send an appropriate
-message can get through to the mailing list cleanly
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id KAA23130
- for
; Fri, 9 Mar 2001 10:49:11 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f29FnFx73540;
- Fri, 9 Mar 2001 10:49:15 -0500 (EST)
-Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80])
- by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f29FmVx73372
- for
; Fri, 9 Mar 2001 10:48:31 -0500 (EST)-Received: from fwd06.sul.t-online.com
- by mailout01.sul.t-online.com with smtp
- id 14bP7X-0001eg-00; Fri, 09 Mar 2001 16:47:59 +0100
-Received: from peter.localdomain (520083510237-0001@[212.185.245.76]) by fmrl06.sul.t-online.com
- with esmtp id 14bP79-1w2fj6C; Fri, 9 Mar 2001 16:47:35 +0100
-Date: Fri, 9 Mar 2001 16:57:18 +0100 (CET)
-To: Tom Lane
-Subject: Re: [HACKERS] Internationalized error messages
-MIME-Version: 1.0
-Content-Type: TEXT/PLAIN; charset=US-ASCII
-Precedence: bulk
-Status: OR
-
-Tom Lane writes:
-
-> There's a difficult tradeoff to make here, but I think we do want to
-> distinguish between the "official error code" --- the thing that has
-> translations into various languages --- and what the backend is actually
-> allowed to print out. It seems to me that a fairly large fraction of
-> the unique messages found in the backend can all be lumped under the
-> category of "internal error", and that we need to have only one official
-> error code and one user-level translated message for the lot of them.
-
-That's exactly what I was trying to avoid. You'd still be allowed to
-choose the error message text freely, but client programs will be able to
-make sense of them by looking at the code only, as opposed to parsing the
-message text. I'm trying to avoid making the message text to be computed
-from the error code, because that obscures the source code.
-
-> Another thing that's bothered me for a long time is our inconsistent
-> approach to determining where in the code a message comes from. A lot
-> of the messages currently embed the name of the generating routine right
-> into the error text. Again, we ought to separate the functionality:
-> the source-code location is valuable but ought not form part of the
-> primary error message. I would like to see elog() become a macro that
-> invokes __FILE__ and __LINE__ to automatically make the *exact* source
-> code location become part of the secondary error information, and then
-> drop the convention of using the routine name in the message text.
-
-These sort of things have been on my mind as well, but they're really
-independent of my issue. We can easily have runtime options to append or
-not additional things to the error string. I don't see this as part of my
-proposal.
-
-> Another thing that I missed in Peter's proposal is how we are going to
-> cope with messages that include parameters. Surely we do not expect
-> gettext to start with 'Attribute "foo" not found' and distinguish fixed
-> >from variable parts of that string?
-
-Sure we do.
-
-> That would mean we'd have to dump all the info into a single string,
-> which is doable but would perhaps look pretty ugly:
->
-> ERROR: Attribute "foo" not found -- basic message for dumb frontends
-> ERRORCODE: UNREC_IDENT -- key for finding localized message
-
-There should not be a "key" to look up localized messages. Remember that
-the localization will also have to be done in all the front-end programs.
-Surely we do not wish to make a list of messages that pg_dump or psql
-print out. Gettext takes care of this stuff. The only reason why we need
-error codes is for the sake of ease of interpreting by programs.
-
-> PARAM1: foo -- something to embed in the localized message
-
-Not necessary.
-
-> MESSAGE: Attribute or table name not known within context of query
-
-How's that different from ERROR:?
-
-> CODELOC: src/backend/parser/parse_clause.c line 345
-
-Can be appended to ERROR (or MESSAGE) depending on configuration setting.
-
-> QUERYLOC: 22
-
-Not all errors are related to a query.
-
-The general problem here is also that this would introduce a client
-incompatibility. Older clients that do not expect this amount of detail
-will print all this garbage to the screen?
-
---
-
-
----------------------------(end of broadcast)---------------------------
-TIP 5: Have you checked our extensive FAQ?
-
-http://www.postgresql.org/users-lounge/docs/faq.html
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id LAA24084
- for
; Fri, 9 Mar 2001 11:01:42 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f29G1kx75165;
- Fri, 9 Mar 2001 11:01:46 -0500 (EST)
-Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154])
- by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f29G11x75037
- for
; Fri, 9 Mar 2001 11:01:01 -0500 (EST)-Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
- by sss.pgh.pa.us (8.11.1/8.11.1) with ESMTP id f29G0r906898;
- Fri, 9 Mar 2001 11:00:54 -0500 (EST)
-Subject: Re: [HACKERS] Internationalized error messages
-Comments: In-reply-to Peter Eisentraut
- message dated "Fri, 09 Mar 2001 16:57:18 +0100"
-Date: Fri, 09 Mar 2001 11:00:53 -0500
-From: Tom Lane
-Precedence: bulk
-Status: OR
-
-Peter Eisentraut
writes:-> That's exactly what I was trying to avoid. You'd still be allowed to
-> choose the error message text freely, but client programs will be able to
-> make sense of them by looking at the code only, as opposed to parsing the
-> message text. I'm trying to avoid making the message text to be computed
-> from the error code, because that obscures the source code.
-
-I guess I don't understand what you have in mind, because this seems
-self-contradictory. If "client programs can look at the code only",
-then how can the error message text be chosen independently of the code?
-
->> Surely we do not expect gettext to start with 'Attribute "foo" not
->> found' and distinguish fixed from variable parts of that string?
-
-> Sure we do.
-
-How does that work exactly? You're assuming an extremely intelligent
-localization mechanism, I guess, which I was not. I think it makes more
-sense to work a little harder in the backend to avoid requiring AI
-software in every frontend.
-
->> MESSAGE: Attribute or table name not known within context of query
-
-> How's that different from ERROR:?
-
-Sorry, I meant that as an example of the "secondary message string", but
-it's a pretty lame example...
-
-> The general problem here is also that this would introduce a client
-> incompatibility. Older clients that do not expect this amount of detail
-> will print all this garbage to the screen?
-
-Yes, if we send it to them. It would make sense to control the amount
-of detail presented via some option (a GUC variable, probably). For
-backwards compatibility reasons we'd want the default to correspond to
-roughly the existing amount of detail.
-
- regards, tom lane
-
----------------------------(end of broadcast)---------------------------
-TIP 3: if posting/reading through Usenet, please send an appropriate
-message can get through to the mailing list cleanly
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id LAA29403
- for
; Fri, 9 Mar 2001 11:48:02 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f29Gm7x82613;
- Fri, 9 Mar 2001 11:48:07 -0500 (EST)
-Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81])
- by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f29Gftx80866
- for
; Fri, 9 Mar 2001 11:41:55 -0500 (EST)-Received: from fwd06.sul.t-online.com
- by mailout03.sul.t-online.com with smtp
- id 14bPxV-0006Eh-06; Fri, 09 Mar 2001 17:41:41 +0100
-Received: from peter.localdomain (520083510237-0001@[212.185.245.76]) by fmrl06.sul.t-online.com
- with esmtp id 14bPwb-239C4mC; Fri, 9 Mar 2001 17:40:45 +0100
-Date: Fri, 9 Mar 2001 17:50:28 +0100 (CET)
-To: Tom Lane
-Subject: Re: [HACKERS] Internationalized error messages
-MIME-Version: 1.0
-Content-Type: TEXT/PLAIN; charset=US-ASCII
-Precedence: bulk
-Status: OR
-
-Tom Lane writes:
-
-> I guess I don't understand what you have in mind, because this seems
-> self-contradictory. If "client programs can look at the code only",
-> then how can the error message text be chosen independently of the code?
-
-Let's say "type mismatch error", code 2200G acc. to SQL. At one place in
-the source you write
-
-elog(ERROR, "2200G", "type mismatch in CASE expression (%s vs %s)", ...);
-
-Elsewhere you'd write
-
-elog(ERROR, "2200G", "type mismatch in argument %d of function %s,
- expected %s, got %s", ...);
-
-Humans can look at this and have a fairly good idea what they'd need to
-fix. However, a client program currently only has the option of failing
-or not failing. In this example case it would probably better for it to
-fail, but someone else already put forth the example of constraint
-violation. In this case the program might want to do something else.
-
-> >> Surely we do not expect gettext to start with 'Attribute "foo" not
-> >> found' and distinguish fixed from variable parts of that string?
->
-> > Sure we do.
->
-> How does that work exactly? You're assuming an extremely intelligent
-> localization mechanism, I guess, which I was not. I think it makes more
-> sense to work a little harder in the backend to avoid requiring AI
-> software in every frontend.
-
-Gettext takes care of this. In the source you'd write
-
-elog(ERROR, "2200G", gettext("type mismatch in CASE expression (%s vs %s)"),
- string, string);
-
-When you run the xgettext utility program it scans the source for cases of
-gettext(...) and creates message catalogs for the translators. When it
-finds printf arguments it automatically includes marks in the message,
-such as
-
-"type mismatch in CASE expression (%1$s vs %2$s)"
-
-which the translator better keep in his version. This also handles the
-case where the arguments might have to appear in a different order in a
-different language.
-
-> Sorry, I meant that as an example of the "secondary message string", but
-> it's a pretty lame example...
-
-I guess I'm not sold on the concept of primary and secondary message
-strings. If the primary message isn't good enough you better fix that.
-
---
-
-
----------------------------(end of broadcast)---------------------------
-TIP 4: Don't 'kill -9' the postmaster
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id LAA01102
- for
; Fri, 9 Mar 2001 11:58:51 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f29Gwux84498;
- Fri, 9 Mar 2001 11:58:56 -0500 (EST)
-Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81])
- by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f29Gm0x82577
- for
; Fri, 9 Mar 2001 11:48:00 -0500 (EST)-Received: from fwd06.sul.t-online.com
- by mailout03.sul.t-online.com with smtp
- id 14bQ3Q-0006Eh-05; Fri, 09 Mar 2001 17:47:48 +0100
-Received: from peter.localdomain (520083510237-0001@[212.185.245.76]) by fmrl06.sul.t-online.com
- with esmtp id 14bQ39-0bSV4SC; Fri, 9 Mar 2001 17:47:31 +0100
-Date: Fri, 9 Mar 2001 17:57:13 +0100 (CET)
-To: Karel Zak
-Subject: Re: [HACKERS] Internationalized error messages
-MIME-Version: 1.0
-Content-Type: TEXT/PLAIN; charset=US-ASCII
-Precedence: bulk
-Status: OR
-
-Karel Zak writes:
-
-> For transaltion to other languages I not sure with gettext() stuff on
-> backend -- IMHO better (faster) solution will postgres system catalog
-> with it.
-
-elog(ERROR, "cannot open message catalog table");
-
---
-
-
----------------------------(end of broadcast)---------------------------
-TIP 5: Have you checked our extensive FAQ?
-
-http://www.postgresql.org/users-lounge/docs/faq.html
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id MAA03663
- for
; Fri, 9 Mar 2001 12:08:40 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f29H8fx86748;
- Fri, 9 Mar 2001 12:08:41 -0500 (EST)
-Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154])
- by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f29H5Px86225
- for
; Fri, 9 Mar 2001 12:05:25 -0500 (EST)-Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
- by sss.pgh.pa.us (8.11.1/8.11.1) with ESMTP id f29H5M907103;
- Fri, 9 Mar 2001 12:05:22 -0500 (EST)
-Subject: Re: [HACKERS] Internationalized error messages
-Comments: In-reply-to Peter Eisentraut
- message dated "Fri, 09 Mar 2001 17:50:28 +0100"
-Date: Fri, 09 Mar 2001 12:05:22 -0500
-From: Tom Lane
-Precedence: bulk
-Status: OR
-
-Peter Eisentraut
writes:-> Let's say "type mismatch error", code 2200G acc. to SQL. At one place in
-> the source you write
-> elog(ERROR, "2200G", "type mismatch in CASE expression (%s vs %s)", ...);
-> Elsewhere you'd write
-> elog(ERROR, "2200G", "type mismatch in argument %d of function %s,
-> expected %s, got %s", ...);
-
-Okay, so your notion of an error code is not a localizable entity at
-all, it's something for client programs to look at. Now I get it.
-
-I object to writing "2200G" however, because that has no mnemonic value
-whatever, and is much too easy to get wrong. How about
-
-elog(ERROR, ERR_TYPE_MISMATCH, "type mismatch in argument %d of function %s,
- expected %s, got %s", ...);
-
-where ERR_TYPE_MISMATCH is #defined as "2200G" someplace? Or for that
-matter #defined as "TYPE_MISMATCH"? Content-free numeric codes are no
-fun to use on the client side either...
-
-> Gettext takes care of this. In the source you'd write
-
-> elog(ERROR, "2200G", gettext("type mismatch in CASE expression (%s vs %s)"),
-> string, string);
-
-Duh. For some reason I was envisioning the localization substitution as
-occurring on the client side, but of course we'd want to do it on the
-server side, and before parameters are substituted into the message.
-Sorry for the noise.
-
-I am not sure we can/should use gettext (possible license problems?),
-but certainly something like this could be cooked up.
-
->> Sorry, I meant that as an example of the "secondary message string", but
->> it's a pretty lame example...
-
-> I guess I'm not sold on the concept of primary and secondary message
-> strings. If the primary message isn't good enough you better fix that.
-
-The motivation isn't so much to improve on the primary message as to
-reduce the number of distinct strings that really need to be translated.
-Remember all those internal "can't happen" errors. If we have only one
-message component then the translator is faced with a huge pile of
-internal messages and not a lot of gain from translating them. If
-there's a primary and secondary component then all the internal messages
-can share the same primary component ("Internal error, please file a bug
-report"). Now the translator translates that one message, and can
-ignore the many secondary-component messages with a clear conscience.
-(Of course, he can translate those too if he really wants to, but the
-point is that he doesn't *have* to do it to attain reasonably friendly
-behavior.)
-
-Perhaps another way to look at it is that we have a bunch of errors that
-are user-oriented (ie, relate pretty directly to something the user did
-wrong) and another bunch that are system-oriented (relate to internal
-problems, such as consistency check failures or violations of internal
-APIs). We want to provide localized translations of the first set, for
-sure. I don't think we need localized translations of the second set,
-so long as we have some sort of "covering message" that can be localized
-for them. Maybe instead of "primary" and "secondary" strings for a
-single error, we ought to distinguish these two categories of error and
-plan different localization strategies for them.
-
- regards, tom lane
-
----------------------------(end of broadcast)---------------------------
-TIP 2: you can get off all lists at once with the unregister command
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id OAA13877
- for
; Fri, 9 Mar 2001 14:43:44 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f29Jhlx10520;
- Fri, 9 Mar 2001 14:43:47 -0500 (EST)
-Received: from exup.z.zembu.com (nat.zembu.com [209.128.96.253])
- by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f29JhLx10390
- for
; Fri, 9 Mar 2001 14:43:22 -0500 (EST)-Received: from andrew by exup.z.zembu.com with local (Exim 3.12 #1 (Debian))
- id 14bSnI-0003Qy-00
- for
; Fri, 09 Mar 2001 11:43:20 -0800-Date: Fri, 9 Mar 2001 11:43:20 -0800
-Subject: Re: [HACKERS] Internationalized error messages
-Mime-Version: 1.0
-Content-Type: text/plain; charset=us-ascii
-Content-Disposition: inline
-Precedence: bulk
-Status: OR
-
-> Peter Eisentraut
writes:-> > Let's say "type mismatch error", code 2200G acc. to SQL. At one place in
-> > the source you write
-> > elog(ERROR, "2200G", "type mismatch in CASE expression (%s vs %s)", ...);
-
-Tom Lane spake:
-> I object to writing "2200G" however, because that has no mnemonic value
-> whatever, and is much too easy to get wrong. How about
->
-> elog(ERROR, ERR_TYPE_MISMATCH, "type mismatch in argument %d of function %s,
-> expected %s, got %s", ...);
->
-> where ERR_TYPE_MISMATCH is #defined as "2200G" someplace? Or for that
-> matter #defined as "TYPE_MISMATCH"? Content-free numeric codes are no
-> fun to use on the client side either...
-
-This is one thing I think VMS does well. All error messages are a
-composite of the subsystem where they originated, the severity of the
-error, and the actual error itself. Internally this is stored in a
-32-bit word. It's been a long time, so I don't recall how many bits
-they allocated for each component. The human-readable representation
-looks like "--".
-
---
-Andrew Evans
-
----------------------------(end of broadcast)---------------------------
-TIP 4: Don't 'kill -9' the postmaster
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id OAA15747
- for
; Fri, 9 Mar 2001 14:58:31 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f29JwYx12257;
- Fri, 9 Mar 2001 14:58:34 -0500 (EST)
-Received: from store.d.zembu.com (nat.zembu.com [209.128.96.253])
- by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f29JnJx11198
- for
; Fri, 9 Mar 2001 14:49:19 -0500 (EST)-Received: by store.d.zembu.com (Postfix, from userid 509)
- id 0552DA75B; Fri, 9 Mar 2001 11:49:21 -0800 (PST)
-Date: Fri, 9 Mar 2001 11:49:20 -0800
-Subject: Re: [HACKERS] Internationalized error messages
-Mime-Version: 1.0
-Content-Type: text/plain; charset=us-ascii
-Content-Disposition: inline
-User-Agent: Mutt/1.2.5i
-Precedence: bulk
-Status: OR
-
-On Fri, Mar 09, 2001 at 12:05:22PM -0500, Tom Lane wrote:
-> > Gettext takes care of this. In the source you'd write
->
-> > elog(ERROR, "2200G", gettext("type mismatch in CASE expression (%s vs %s)"),
-> > string, string);
->
-> Duh. For some reason I was envisioning the localization substitution as
-> occurring on the client side, but of course we'd want to do it on the
-> server side, and before parameters are substituted into the message.
-> Sorry for the noise.
->
-> I am not sure we can/should use gettext (possible license problems?),
-> but certainly something like this could be cooked up.
-
-I've been assuming that PG's needs are specialized enough that the
-project wouldn't use gettext directly, but instead something inspired
-by it.
-
-If you look at my last posting on the subject, by the way, you will see
-that it could work without a catalog underneath; integrating a catalog
-would just require changes in a header file (and the programs to generate
-the catalog, of course). That quality seems to me essential to allow the
-changeover to be phased in gradually, and to allow different underlying
-catalog implementations to be tried out.
-
-Nathan
-ncm
-
----------------------------(end of broadcast)---------------------------
-TIP 5: Have you checked our extensive FAQ?
-
-http://www.postgresql.org/users-lounge/docs/faq.html
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id PAA19742
- for
; Fri, 9 Mar 2001 15:36:00 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f29Ka3x19411;
- Fri, 9 Mar 2001 15:36:03 -0500 (EST)
-Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82])
- by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f29KZfx19290
- for
; Fri, 9 Mar 2001 15:35:41 -0500 (EST)-Received: from fwd03.sul.t-online.com
- by mailout05.sul.t-online.com with smtp
- id 14bTbq-0007l3-0G; Fri, 09 Mar 2001 21:35:34 +0100
-Received: from peter.localdomain (520083510237-0001@[212.185.245.76]) by fmrl03.sul.t-online.com
- with esmtp id 14bTbm-0MoEWuC; Fri, 9 Mar 2001 21:35:30 +0100
-Date: Fri, 9 Mar 2001 21:45:14 +0100 (CET)
-To: Tom Lane
-Subject: Re: [HACKERS] Internationalized error messages
-MIME-Version: 1.0
-Content-Type: TEXT/PLAIN; charset=US-ASCII
-Precedence: bulk
-Status: OR
-
-Tom Lane writes:
-
-> I object to writing "2200G" however, because that has no mnemonic value
-> whatever, and is much too easy to get wrong. How about
->
-> elog(ERROR, ERR_TYPE_MISMATCH, "type mismatch in argument %d of function %s,
-> expected %s, got %s", ...);
->
-> where ERR_TYPE_MISMATCH is #defined as "2200G" someplace? Or for that
-> matter #defined as "TYPE_MISMATCH"? Content-free numeric codes are no
-> fun to use on the client side either...
-
-Well, SQL defines these. Do we want to make our own list? However,
-numeric codes also have the advantage that some hierarchy is possible.
-E.g., the "22" in "2200G" is actually the category code "data exception".
-Personally, I would stick to the SQL codes but make some readable macro
-name for backend internal use.
-
-> I am not sure we can/should use gettext (possible license problems?),
-
-Gettext is an open standard, invented at Sun IIRC. There is also an
-independent implementation for BSDs in the works. On GNU/Linux system
-it's in the C library. I don't see any license problems that way. Is has
-been used widely for free software and so far I haven't seen any real
-alternative.
-
-> but certainly something like this could be cooked up.
-
-Well, I'm trying to avoid having to do the cooking. ;-)
-
-> Perhaps another way to look at it is that we have a bunch of errors that
-> are user-oriented (ie, relate pretty directly to something the user did
-> wrong) and another bunch that are system-oriented (relate to internal
-> problems, such as consistency check failures or violations of internal
-> APIs). We want to provide localized translations of the first set, for
-> sure. I don't think we need localized translations of the second set,
-> so long as we have some sort of "covering message" that can be localized
-> for them.
-
-I'm sure this can be covered in some macro way. A random idea:
-
-elog(ERROR, INTERNAL_ERROR("text"), ...)
-
-expands to
-
-elog(ERROR, gettext("Internal error: %s"), ...)
-
-OTOH, we should not yet make presumptions about what dedicated translators
-can be capable of. :-)
-
---
-
-
----------------------------(end of broadcast)---------------------------
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id PAA20321
- for
; Fri, 9 Mar 2001 15:49:07 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f29Kn8x21185;
- Fri, 9 Mar 2001 15:49:09 -0500 (EST)
-Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154])
- by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f29Kmbx20959
- for
; Fri, 9 Mar 2001 15:48:37 -0500 (EST)-Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
- by sss.pgh.pa.us (8.11.1/8.11.1) with ESMTP id f29KmX908663;
- Fri, 9 Mar 2001 15:48:33 -0500 (EST)
-Subject: Re: [HACKERS] Internationalized error messages
-Comments: In-reply-to Peter Eisentraut
- message dated "Fri, 09 Mar 2001 21:45:14 +0100"
-Date: Fri, 09 Mar 2001 15:48:33 -0500
-From: Tom Lane
-Precedence: bulk
-Status: OR
-
-Peter Eisentraut
writes:-> Well, SQL defines these. Do we want to make our own list? However,
-> numeric codes also have the advantage that some hierarchy is possible.
-> E.g., the "22" in "2200G" is actually the category code "data exception".
-> Personally, I would stick to the SQL codes but make some readable macro
-> name for backend internal use.
-
-We will probably find cases where we need codes not defined by SQL
-(since we have non-SQL features). If there is room to invent our
-own codes then I have no objection to this.
-
->> I am not sure we can/should use gettext (possible license problems?),
-
-> Gettext is an open standard, invented at Sun IIRC. There is also an
-> independent implementation for BSDs in the works. On GNU/Linux system
-> it's in the C library. I don't see any license problems that way.
-
-Unless that BSD implementation is ready to go, I think we'd be talking
-about relying on GPL'd (not LGPL'd) code for an essential component of
-the system functionality. Given RMS' recent antics I am much less
-comfortable with that than I might once have been.
-
- regards, tom lane
-
----------------------------(end of broadcast)---------------------------
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id IAA03404
- for
; Tue, 13 Mar 2001 08:13:35 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f2DDCix16410;
- Tue, 13 Mar 2001 08:12:44 -0500 (EST)
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f2DDC4x16226
- for
; Tue, 13 Mar 2001 08:12:04 -0500 (EST)-Received: from nemeton.com.au (202-76-170-108.dialin.swift.net.au [202.76.170.108])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f2AM2xx82737
- for
; Sat, 10 Mar 2001 17:03:00 -0500 (EST)-Received: (qmail 5430 invoked from network); 10 Mar 2001 22:02:16 -0000
-Received: from nemeton.com.au (203.8.3.33)
- by nemeton.com.au with SMTP; 10 Mar 2001 22:02:16 -0000
-Subject: Re: [HACKERS] Internationalized error messages
-In-Reply-To: Message from Tom Lane
-Date: Sun, 11 Mar 2001 09:02:16 +1100
-From: Giles Lean
-Precedence: bulk
-Status: OR
-
-
-Tom Lane wrote:
-
-> I am not sure we can/should use gettext (possible license problems?),
-> but certainly something like this could be cooked up.
-
-http://citrus.bsdclub.org/index-en.html
-
-I'm not sure of the current status of the code.
-
-Regards,
-
-Giles
-
-
----------------------------(end of broadcast)---------------------------
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id KAA10081
- for
; Tue, 13 Mar 2001 10:01:03 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f2DF01x32641;
- Tue, 13 Mar 2001 10:00:01 -0500 (EST)
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f2DESJx26149
- for
; Tue, 13 Mar 2001 09:28:19 -0500 (EST)-Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130])
- by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f2BIBGx97386
- for
; Sun, 11 Mar 2001 13:11:16 -0500 (EST)-Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk)
- by henry.newn.cam.ac.uk with esmtp (Exim 3.13 #1)
- id 14cAJ4-0002pP-00; Sun, 11 Mar 2001 18:11:02 +0000
-Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 3.13 #1)
- id 14cAJ4-0002Em-00; Sun, 11 Mar 2001 18:11:02 +0000
-Date: Sun, 11 Mar 2001 18:11:02 +0000
-To: Tom Lane
-Subject: Re: [HACKERS] Internationalized error messages
-Mime-Version: 1.0
-Content-Type: text/plain; charset=us-ascii
-Content-Disposition: inline
-User-Agent: Mutt/1.2i
-Precedence: bulk
-Status: OR
-
-On Fri, Mar 09, 2001 at 03:48:33PM -0500, Tom Lane wrote:
-> Peter Eisentraut
writes:-> > Well, SQL defines these. Do we want to make our own list? However,
-> > numeric codes also have the advantage that some hierarchy is possible.
-> > E.g., the "22" in "2200G" is actually the category code "data exception".
-> > Personally, I would stick to the SQL codes but make some readable macro
-> > name for backend internal use.
->
-> We will probably find cases where we need codes not defined by SQL
-> (since we have non-SQL features). If there is room to invent our
-> own codes then I have no objection to this.
->
-> >> I am not sure we can/should use gettext (possible license problems?),
->
-> > Gettext is an open standard, invented at Sun IIRC. There is also an
-> > independent implementation for BSDs in the works. On GNU/Linux system
-> > it's in the C library. I don't see any license problems that way.
->
-> Unless that BSD implementation is ready to go, I think we'd be talking
-> about relying on GPL'd (not LGPL'd) code for an essential component of
-> the system functionality. Given RMS' recent antics I am much less
-> comfortable with that than I might once have been.
-
-cf. http://citrus.bsdclub.org/
-
-and the libintl in NetBSD, at least NetBSD-current, works. The hard part
-was eg convincing gmake's configure to use it as there are bits like
-
-#if __USE_GNU_GETTEXT
-
-rather than just checking for the existence of the functions (as well as
-the internal symbol _nl_msg_cat_cntr).
-
-So yes it's ready to go, but please don't use the same m4 in configure.in as
-for GNU gettext.
-
-Cheers,
-
-Patrick
-
----------------------------(end of broadcast)---------------------------
-TIP 2: you can get off all lists at once with the unregister command
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id IAA29321
- for
; Mon, 12 Mar 2001 08:38:57 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f2CDbhx08914;
- Mon, 12 Mar 2001 08:37:43 -0500 (EST)
-Received: from ara.zf.jcu.cz ([160.217.161.4])
- by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f2CCDQx02184
- for
; Mon, 12 Mar 2001 07:13:26 -0500 (EST)-Received: (from zakkr@localhost)
- by ara.zf.jcu.cz (8.9.3/8.9.3/Debian 8.9.3-21) id KAA03098;
- Mon, 12 Mar 2001 10:32:34 +0100
-Date: Mon, 12 Mar 2001 10:32:33 +0100
-From: Karel Zak
-Cc: Karel Zak , Tom Lane ,
-Subject: Re: [HACKERS] Internationalized error messages
-Mime-Version: 1.0
-Content-Type: text/plain; charset=us-ascii
-User-Agent: Mutt/1.0.1i
-Precedence: bulk
-Status: OR
-
-On Fri, Mar 09, 2001 at 05:57:13PM +0100, Peter Eisentraut wrote:
-> Karel Zak writes:
->
-> > For transaltion to other languages I not sure with gettext() stuff on
-> > backend -- IMHO better (faster) solution will postgres system catalog
-> > with it.
->
-> elog(ERROR, "cannot open message catalog table");
-
- Sure, and what:
-
-elog(ERROR, gettext("can't set LC_MESSAGES"));
-
- We can generate our system catalog for this by simular way as gettext, it's
-means all messages can be in sources in English too.
-
- But this is reflexion, performance test show more.
-
- Karel
-
---
- Karel Zak
- http://home.zf.jcu.cz/~zakkr/
-
- C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
-
----------------------------(end of broadcast)---------------------------
-TIP 5: Have you checked our extensive FAQ?
-
-http://www.postgresql.org/users-lounge/docs/faq.html
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id LAA06736
- for
; Mon, 12 Mar 2001 11:30:23 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f2CGUSx29891;
- Mon, 12 Mar 2001 11:30:28 -0500 (EST)
-Received: from mail.retep.org.uk ([216.126.85.184])
- by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f2CGCYx27481
- for
; Mon, 12 Mar 2001 11:12:34 -0500 (EST)-Received: from heather.retep.org.uk ([193.113.113.179])
- (authenticated)
- by mail.retep.org.uk (8.11.1/8.11.1) with ESMTP id f2CGCQR27465;
- Mon, 12 Mar 2001 11:12:26 -0500 (EST)
-X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
-Date: Mon, 12 Mar 2001 15:09:53 +0000
-Subject: Re: [HACKERS] Internationalized error messages
-Mime-Version: 1.0
-Content-Type: text/plain; charset="us-ascii"; format=flowed
-Precedence: bulk
-Status: OR
-
-At 23:49 08/03/01 +0100, Peter Eisentraut wrote:
->I really feel that translated error messages need to happen soon.
->Managing translated message catalogs can be done easily with available
->APIs. However, translatable messages really require an error code
->mechanism (otherwise it's completely impossible for programs to interpret
->error messages reliably). I've been thinking about this for much too long
->now and today I finally settled to the simplest possible solution.
->
->Let the actual method of allocating error codes be irrelevant for now,
->although the ones in the SQL standard are certainly to be considered for a
->start. Essentially, instead of writing
-
-snip
-
->On the protocol front, this could be pretty easy to do. Instead of
->"message text" we'd send a string "XYZ01: message text". Worst case, we
->pass this unfiltered to the client and provide an extra function that
->returns only the first five characters. Alternatively we could strip off
->the prefix when returning the message text only.
-
-Most other DB's (I'm thinking of Oracle here) pass the code unfiltered to
-the client anyhow. Saying that, it's not impossible to get psql and other
-interactive clients to strip the error code anyhow.
-
-
->At the end, the i18n part would actually be pretty easy, e.g.,
->
-> elog(ERROR, "XYZ01", gettext("stuff happened"));
->
->
->Comments? Better ideas?
-
-A couple of ideas. One, if we have a master list of error codes, we need to
-have this in an independent format (ie not a .h file). However the other
-idea is to expand on the JDBC's errors.properties files. Being
-ascii/unicode, the format will work with just some extra code to implement
-them in C.
-
-Brief description:
-------------------------
-
-The ResourceBundle's handle one language per file. From a base filename,
-each different language has a file based on:
-
- filename_la_ct.properties
-
-where la is the ISO 2 character language, and ct is the ISO 2 character
-country code.
-
-For example:
-
-messages_en_GB.properties
-messages_en_US.properties
-messages_en.properties
-messages_fr.properties
-messages.properties
-
-Now, here for the english locale for England it checks in this order:
-messages_en_GB.properties messages_en.properties messages.properties.
-
-In each file, a message is of the format:
-
-key=message, and each parameter passed into the message written like {1}
-{2} etc, so for example:
-
-fathom=Unable to fathom update count {0}
-
-Now apart from the base file (messages.properties in this case), the other
-files are optional, and an entry only needs to be in there if they are
-present in that language.
-
-So, in french, fathom may be translated, but then again it may not (in JDBC
-it isn't). Then it's not included in the file. Any new messages can be
-added to the base language, but only included as and when they are translated.
-
-Peter
-
-
----------------------------(end of broadcast)---------------------------
-TIP 6: Have you searched our list archives?
-
-http://www.postgresql.org/search.mpl
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id OAA13271
- for
; Mon, 12 Mar 2001 14:12:36 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f2CJAMx49815;
- Mon, 12 Mar 2001 14:10:22 -0500 (EST)
-Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81])
- by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f2CJ5kx49312
- for
; Mon, 12 Mar 2001 14:05:46 -0500 (EST)-Received: from fwd05.sul.t-online.com
- by mailout03.sul.t-online.com with smtp
- id 14cXdC-0005sr-00; Mon, 12 Mar 2001 20:05:22 +0100
-Received: from peter.localdomain (520083510237-0001@[212.185.245.45]) by fmrl05.sul.t-online.com
- with esmtp id 14cXd2-1UHYcCC; Mon, 12 Mar 2001 20:05:12 +0100
-Date: Mon, 12 Mar 2001 20:15:02 +0100 (CET)
-To: Karel Zak
-Subject: Re: [HACKERS] Internationalized error messages
-MIME-Version: 1.0
-Content-Type: TEXT/PLAIN; charset=US-ASCII
-Precedence: bulk
-Status: OR
-
-Karel Zak writes:
-
-> > > For transaltion to other languages I not sure with gettext() stuff on
-> > > backend -- IMHO better (faster) solution will postgres system catalog
-> > > with it.
-> >
-> > elog(ERROR, "cannot open message catalog table");
->
-> Sure, and what:
->
-> elog(ERROR, gettext("can't set LC_MESSAGES"));
->
-> We can generate our system catalog for this by simular way as gettext, it's
-> means all messages can be in sources in English too.
-
-When there is an error condition in the backend, the last thing you want
-to do (and are allowed to do) is accessing tables. Also keep in mind that
-we want to internationalize other parts of the system as well, such as
-pg_dump and psql.
-
---
-
-
----------------------------(end of broadcast)---------------------------
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id CAA18106
- for
; Tue, 13 Mar 2001 02:41:01 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f2D7dWx73584;
- Tue, 13 Mar 2001 02:39:32 -0500 (EST)
-Received: from ara.zf.jcu.cz (ara.zf.jcu.cz [160.217.161.4])
- by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f2D7V5x72953
- for
; Tue, 13 Mar 2001 02:31:05 -0500 (EST)-Received: (from zakkr@localhost)
- by ara.zf.jcu.cz (8.9.3/8.9.3/Debian 8.9.3-21) id IAA26971;
- Tue, 13 Mar 2001 08:30:59 +0100
-Date: Tue, 13 Mar 2001 08:30:59 +0100
-From: Karel Zak
-Cc: Karel Zak , Tom Lane ,
-Subject: Re: [HACKERS] Internationalized error messages
-Mime-Version: 1.0
-Content-Type: text/plain; charset=us-ascii
-User-Agent: Mutt/1.0.1i
-Precedence: bulk
-Status: OR
-
-On Mon, Mar 12, 2001 at 08:15:02PM +0100, Peter Eisentraut wrote:
-> Karel Zak writes:
->
-> > > > For transaltion to other languages I not sure with gettext() stuff on
-> > > > backend -- IMHO better (faster) solution will postgres system catalog
-> > > > with it.
-> > >
-> > > elog(ERROR, "cannot open message catalog table");
-> >
-> > Sure, and what:
-> >
-> > elog(ERROR, gettext("can't set LC_MESSAGES"));
-> >
-> > We can generate our system catalog for this by simular way as gettext, it's
-> > means all messages can be in sources in English too.
->
-> When there is an error condition in the backend, the last thing you want
-> to do (and are allowed to do) is accessing tables. Also keep in mind that
-> we want to internationalize other parts of the system as well, such as
-> pg_dump and psql.
-
- Agree, the pg_xxxx application are good adepts for POSIX locales, all my
-previous notes are about backend error/notice messages, but forget it --
-after implementation we will more judicious.
-
---
- Karel Zak
- http://home.zf.jcu.cz/~zakkr/
-
- C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
-
----------------------------(end of broadcast)---------------------------
-TIP 4: Don't 'kill -9' the postmaster
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id RAA09211
- for
; Mon, 19 Mar 2001 17:58:40 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2JMw5N07189;
- Mon, 19 Mar 2001 17:58:05 -0500 (EST)
-Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2JMkaN84648
- for
; Mon, 19 Mar 2001 17:46:36 -0500 (EST)-Received: from fwd03.sul.t-online.com
- by mailout03.sul.t-online.com with smtp
- id 14f8Q5-0007Mt-01; Mon, 19 Mar 2001 23:46:33 +0100
-Received: from peter.localdomain (520083510237-0001@[217.80.146.106]) by fmrl03.sul.t-online.com
- with esmtp id 14f8Px-15zChUC; Mon, 19 Mar 2001 23:46:25 +0100
-Date: Mon, 19 Mar 2001 23:56:32 +0100 (CET)
-To: PostgreSQL Development
-Subject: [HACKERS] More on elog and error codes
-MIME-Version: 1.0
-Content-Type: TEXT/PLAIN; charset=US-ASCII
-Precedence: bulk
-Status: OR
-
-I've looked at the elog calls in the source, about 1700 in total (only
-elog(ERROR)). If we mapped these to the SQL error codes then we'd have
-about two dozen calls with an assigned code and the rest being "other".
-The way I estimate it (I didn't really look at *each* call, of course) is
-that about 2/3 of the calls are internal panic calls ("cache lookup of %s
-failed"), 1/6 are SQL-level problems, and the rest are operating system,
-storage problems, "not implemented", misconfigurations, etc.
-
-A problem that makes this quite hard to manage is that many errors can be
-reported from several places, e.g., the parser, the executor, the access
-method. Some of these messages are probably not readily reproduceable
-because they are caught elsewhere.
-
-Consequentially, the most pragmatic approach to assigning error codes
-might be to just pick some numbers and give them out gradually. A
-hierarchical subsystem+code might be useful, beyond that it really depends
-on what we expect from error codes in the first place. Does anyone have
-good experiences from other products?
-
-Essentially, I envision making up a new function, say "elogc", which has
-
- elogc(, [,?] , message...)
-
-where the code is some macro, the expansion of which is to be determined.
-A call to "elogc" would also require a formalized message wording, adding
-the error code to the documentation, which also requires having a fairly
-good idea how the error can happen and how to handle it. This could
-perhaps even be automated to some extent.
-
-All the calls that are not converted yet will be assigned a to the generic
-"internal error" class; most of them will stay this way.
-
-
-As for translations, I don't think we have to worry about this right now.
-Assuming that we would use gettext or something similar, we can tell it
-that all calls to elog (or "elogc" or whatever) contain translatable
-strings, so we don't have to uglify it with gettext(...) or _(...) calls
-or what else.
-
-
-So we need some good error numbering scheme. Any ideas?
-
---
-
-
----------------------------(end of broadcast)---------------------------
-TIP 6: Have you searched our list archives?
-
-http://www.postgresql.org/search.mpl
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id TAA13745
- for
; Mon, 19 Mar 2001 19:19:37 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2K0J2N56455;
- Mon, 19 Mar 2001 19:19:02 -0500 (EST)
-Received: from acheron.rime.com.au (albatr.lnk.telstra.net [139.130.54.222])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2JNnEN15608
- for
; Mon, 19 Mar 2001 18:49:14 -0500 (EST)-Received: from oberon (Oberon.rime.com.au [203.8.195.100])
- by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id KAA19461;
- Tue, 20 Mar 2001 10:48:55 +1100
-X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
-Date: Tue, 20 Mar 2001 10:48:55 +1100
-Subject: Re: [HACKERS] More on elog and error codes
-Mime-Version: 1.0
-Content-Type: text/plain; charset="us-ascii"
-Precedence: bulk
-Status: OR
-
-At 23:56 19/03/01 +0100, Peter Eisentraut wrote:
->
->Essentially, I envision making up a new function, say "elogc", which has
->
-> elogc(, [,?] , message...)
->
->where the code is some macro, the expansion of which is to be determined.
->A call to "elogc" would also require a formalized message wording, adding
->the error code to the documentation, which also requires having a fairly
->good idea how the error can happen and how to handle it. This could
->perhaps even be automated to some extent.
->
->All the calls that are not converted yet will be assigned a to the generic
->"internal error" class; most of them will stay this way.
->
-...
->
->So we need some good error numbering scheme. Any ideas?
->
-
-FWIW, the VMS scheme has error numbers broken down to include system,
-subsystem, error number & severity. These are maintained in an error
-message source file. eg. the file system's 'file not found' error message
-is something like:
-
-FACILITY RMS (the file system)
-...
-SEVERITY WARNING
-...
-FILNFND "File %AS not found"
-...
-
-It's a while since I used VMS messages files regularly, this is at least
-representative. It has the drawback that severity is often tied to the
-message, not the circumstance, but this is a problem only rarely.
-
-In code, the messages are used as external symbols (probably in our case
-representing pointers to C format strings). In making extensive use of such
-a mnemonics, I never really needed to have full text messages. Once a set
-of standards is in place for message abbreviations, the most people can
-read the message codes. This would mean that:
-
- elogc(, [,?] , message...)
-
-becomes:
-
- elogc( [, parameter...])
-
-eg.
-
- "cache lookup of %s failed"
-
-might be replaced by:
-
- elog(CACHELOOKUPFAIL, cacheItemThatFailed);
-
-and
- "internal error: %s"
-
-becomes
-
- elog(INTERNAL, "could not find the VeryImportantThing");
-
-Unlike VMS, it's probably a good idea to separate the severity from the
-error code, since a CACHELOOKUPFAIL in one place may be less significant
-than another (eg. severity=debug).
-
-I also think it's important that we get the source file and line number
-somewhere in the message, and if we have these, we may not need the subsystem.
-
-
-
-----------------------------------------------------------------
-Philip Warner | __---_____
-Albatross Consulting Pty. Ltd. |----/ - \
-(A.B.N. 75 008 659 498) | /(@) ______---_
-Tel: (+61) 0500 83 82 81 | _________ \
-Fax: (+61) 0500 83 82 82 | ___________ |
-Http://www.rhyme.com.au | / \|
- | --________--
-PGP key available upon request, | /
-and from pgp5.ai.mit.edu:11371 |/
-
----------------------------(end of broadcast)---------------------------
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id TAA15177
- for
; Mon, 19 Mar 2001 19:36:40 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2K0ZvN60485;
- Mon, 19 Mar 2001 19:35:57 -0500 (EST)
-Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2K0ZbN60358
- for
; Mon, 19 Mar 2001 19:35:37 -0500 (EST)-Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
- by sss.pgh.pa.us (8.11.1/8.11.1) with ESMTP id f2K0ZMt08329;
- Mon, 19 Mar 2001 19:35:22 -0500 (EST)
-Subject: Re: [HACKERS] More on elog and error codes
-Comments: In-reply-to Philip Warner
- message dated "Tue, 20 Mar 2001 10:48:55 +1100"
-Date: Mon, 19 Mar 2001 19:35:22 -0500
-From: Tom Lane
-Precedence: bulk
-Status: OR
-
-> I also think it's important that we get the source file and line number
-> somewhere in the message, and if we have these, we may not need the
-> subsystem.
-
-I agree that the subsystem concept is not necessary, except possibly as
-a means of avoiding collisions in the error-symbol namespace, and for
-that it would only be a naming convention (PGERR_subsys_IDENTIFIER).
-We probably do not need it considering that we have much less than 1000
-distinct error identifiers to assign, judging from Peter's survey.
-
-We do need severity to be distinct from the error code ("internal
-errors" are surely not all the same severity, even if we don't bother
-to assign formal error codes to each one).
-
-BTW, the symbols used in the source code do need to have a common prefix
-(PGERR_CACHELOOKUPFAIL not CACHELOOKUPFAIL) to avoid namespace pollution
-problems. We blew this before with "DEBUG" and friends, let's learn
-from that mistake.
-
- regards, tom lane
-
----------------------------(end of broadcast)---------------------------
-TIP 5: Have you checked our extensive FAQ?
-
-http://www.postgresql.org/users-lounge/docs/faq.html
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id LAA29491
- for
; Tue, 20 Mar 2001 11:30:32 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2KGRqN30235;
- Tue, 20 Mar 2001 11:27:53 -0500 (EST)
-Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2KGQ2N29944
- for
; Tue, 20 Mar 2001 11:26:02 -0500 (EST)-Received: from fwd06.sul.t-online.com
- by mailout05.sul.t-online.com with smtp
- id 14fOx7-0001ta-02; Tue, 20 Mar 2001 17:25:45 +0100
-Received: from peter.localdomain (520083510237-0001@[217.80.146.107]) by fmrl06.sul.t-online.com
- with esmtp id 14fOww-0JqouOC; Tue, 20 Mar 2001 17:25:34 +0100
-Date: Tue, 20 Mar 2001 17:35:42 +0100 (CET)
-cc: PostgreSQL Development
-Subject: Re: [HACKERS] More on elog and error codes
-MIME-Version: 1.0
-Content-Type: TEXT/PLAIN; charset=US-ASCII
-Precedence: bulk
-Status: OR
-
-Philip Warner writes:
-
-> elog(CACHELOOKUPFAIL, cacheItemThatFailed);
-
-The disadvantage of this approach, which I tried to explain in a previous
-message, is that we might want to have different wordings for different
-occurences of the same class of error.
-
-Additionally, the whole idea behind having error *codes* is that the
-client program can easily distinguish errors that it can handle specially.
-Thus the codes should be numeric or some other short, fixed scheme. In
-the backend they could be replaced by macros.
-
-Example:
-
-#define PGERR_TYPE 1854
-
-/* somewhere... */
-
-elogc(ERROR, PGERR_TYPE, "type %s cannot be created because it already exists", ...)
-
-/* elsewhere... */
-
-elogc(ERROR, PGERR_TYPE, "type %s used as argument %d of function %s doesn't exist", ...)
-
-
-In fact, this is my proposal. The "1854" can be argued, but I like the
-rest.
-
---
-
-
----------------------------(end of broadcast)---------------------------
-TIP 3: if posting/reading through Usenet, please send an appropriate
-message can get through to the mailing list cleanly
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id QAA23182
- for
; Tue, 20 Mar 2001 16:59:29 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2KLwdH05279;
- Tue, 20 Mar 2001 16:58:39 -0500 (EST)
-Received: from mta1-rme.xtra.co.nz (mta1-rme.xtra.co.nz [203.96.92.1])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2KLfiH02063
- for
; Tue, 20 Mar 2001 16:41:45 -0500 (EST)-Received: from berty ([210.54.106.166]) by mta1-rme.xtra.co.nz with SMTP
- id <20010320214348.MNVZ4360745.mta1-rme.xtra.co.nz@berty>;
- Wed, 21 Mar 2001 09:43:48 +1200
-Content-Type: text/plain;
- charset="iso-8859-1"
-From: Christopher Sawtell
-Organization: At Home
-Subject: Re: [HACKERS] More on elog and error codes
-Date: Wed, 21 Mar 2001 09:41:44 +1200
-X-Mailer: KMail [version 1.2]
-MIME-Version: 1.0
-Message-Id: <01032109414401.09393@berty>
-Content-Transfer-Encoding: 8bit
-Precedence: bulk
-Status: OR
-
-On Tue, 20 Mar 2001 10:56, you wrote:
-> I've looked at the elog calls in the source, about 1700 in total (only
-
-[ ... ]
-
-> So we need some good error numbering scheme. Any ideas?
-
-Just that it might be a good idea to incorporate the version / release
-details in some way so that when somebody on the list is squeaking about
-an error message it is obvious to the helper that the advice needed is to
-upgrade from the Cretatious Period version to a modern release, and have
-another go.
-
---
-Sincerely etc.,
-
- NAME Christopher Sawtell
- CELL PHONE 021 257 4451
- ICQ UIN 45863470
- EMAIL csawtell @ xtra . co . nz
- CNOTES ftp://ftp.funet.fi/pub/languages/C/tutorials/sawtell_C.tar.gz
-
- -->> Please refrain from using HTML or WORD attachments in e-mails to me
-<<--
-
-
----------------------------(end of broadcast)---------------------------
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id RAA24116
- for
; Tue, 20 Mar 2001 17:12:06 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2KMBKH08034;
- Tue, 20 Mar 2001 17:11:20 -0500 (EST)
-Received: from wallace.ece.rice.edu (wallace.ece.rice.edu [128.42.12.154])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2KMAxH07894
- for
; Tue, 20 Mar 2001 17:10:59 -0500 (EST)-Received: by rice.edu
- via sendmail from stdin
- id (Debian Smail3.2.0.102)
-Date: Tue, 20 Mar 2001 16:10:57 -0600
-From: "Ross J. Reedstrom"
-To: PostgreSQL Development
-Subject: Re: [HACKERS] More on elog and error codes
-Mail-Followup-To: PostgreSQL Development
-References:
<01032109414401.09393@berty>-Mime-Version: 1.0
-Content-Type: text/plain; charset=us-ascii
-User-Agent: Mutt/1.0i
-In-Reply-To: <01032109414401.09393@berty>; from
[email protected] on Wed, Mar 21, 2001 at 09:41:44AM +1200
-Precedence: bulk
-Status: OR
-
-On Wed, Mar 21, 2001 at 09:41:44AM +1200, Christopher Sawtell wrote:
-> On Tue, 20 Mar 2001 10:56, you wrote:
->
-> Just that it might be a good idea to incorporate the version / release
-> details in some way so that when somebody on the list is squeaking about
-> an error message it is obvious to the helper that the advice needed is to
-> upgrade from the Cretatious Period version to a modern release, and have
-
-ROFL - parsed this as Cretinous period on the first pass.
-
-Ross
-
----------------------------(end of broadcast)---------------------------
-TIP 3: if posting/reading through Usenet, please send an appropriate
-message can get through to the mailing list cleanly
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id RAA29664
- for
; Tue, 20 Mar 2001 17:46:14 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2KMj4H13670;
- Tue, 20 Mar 2001 17:45:04 -0500 (EST)
-Received: from acheron.rime.com.au (albatr.lnk.telstra.net [139.130.54.222])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2KMi3H13356
- for
; Tue, 20 Mar 2001 17:44:04 -0500 (EST)-Received: from oberon (Oberon.rime.com.au [203.8.195.100])
- by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id JAA06820;
- Wed, 21 Mar 2001 09:43:53 +1100
-X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
-Date: Wed, 21 Mar 2001 09:43:52 +1100
-Subject: Re: [HACKERS] More on elog and error codes
-Cc: PostgreSQL Development
-Mime-Version: 1.0
-Content-Type: text/plain; charset="us-ascii"
-Precedence: bulk
-Status: OR
-
-At 17:35 20/03/01 +0100, Peter Eisentraut wrote:
->Philip Warner writes:
->
->> elog(CACHELOOKUPFAIL, cacheItemThatFailed);
->
->The disadvantage of this approach, which I tried to explain in a previous
->message, is that we might want to have different wordings for different
->occurences of the same class of error.
->
->Additionally, the whole idea behind having error *codes* is that the
->client program can easily distinguish errors that it can handle specially.
->Thus the codes should be numeric or some other short, fixed scheme. In
->the backend they could be replaced by macros.
-
-This seems to be just an argument for constructing the value of
-PGERR_CACHELOOKUPFAIL carefully (which is what the VMS message source files
-did). The point is that when they are used by a developer, they are simple.
-
-
-
->#define PGERR_TYPE 1854
->
->/* somewhere... */
->
->elogc(ERROR, PGERR_TYPE, "type %s cannot be created because it already
-exists", ...)
->
->/* elsewhere... */
->
->elogc(ERROR, PGERR_TYPE, "type %s used as argument %d of function %s
-doesn't exist", ...)
->
-
-I can appreciate that there may be cases where the same message is reused,
-but that is where parameter substitution comes in.
-
-In the specific example above, returning the same error code is not going
-to help the client. What if they want to handle "type %s used as argument
-%d of function %s doesn't exist" by creating the type, and silently ignore
-"type %s cannot be created because it already exists"?
-
-How do you handle "type %s can not be used as a function return type"? Is
-this PGERR_FUNC or PGERR_TYPE?
-
-If the motivation behind this is to alloy easy translation to SQL error
-codes, then I suggest we have an error definition file with explicit
-translation:
-
-Code SQL Text
-PGERR_TYPALREXI 02xxx "type %s cannot be created because it already exists"
-PGERR_FUNCNOTYPE 02xxx "type %s used as argument %d of function %s doesn't
-exist"
-
-and if we want a generic 'type does not exist', then:
-
-PGERR_NOSUCHTYPE 02xxx "type %s does not exist - %s"
-
-where the %s might contain 'it can't be used as a function argument'.
-
-the we just have
-
-elogc(ERROR, PGERR_TYPALEXI, ...)
-
-/* elsewhere... */
-
-elogc(ERROR, PGERR_FUNCNOTYPE, ...)
-
-
-Creating central message files/objects has the added advantage of a much
-simpler locale support - they're just resource files, and they're NOT
-embedded throughout the code.
-
-Finally, if you do want to have some kind of error classification beyond
-the SQL code, it could be encoded in the error message file.
-
-
-----------------------------------------------------------------
-Philip Warner | __---_____
-Albatross Consulting Pty. Ltd. |----/ - \
-(A.B.N. 75 008 659 498) | /(@) ______---_
-Tel: (+61) 0500 83 82 81 | _________ \
-Fax: (+61) 0500 83 82 82 | ___________ |
-Http://www.rhyme.com.au | / \|
- | --________--
-PGP key available upon request, | /
-and from pgp5.ai.mit.edu:11371 |/
-
----------------------------(end of broadcast)---------------------------
-TIP 6: Have you searched our list archives?
-
-http://www.postgresql.org/search.mpl
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id RAA29776
- for
; Tue, 20 Mar 2001 17:48:12 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2KMlVH14127;
- Tue, 20 Mar 2001 17:47:31 -0500 (EST)
-Received: from acheron.rime.com.au (albatr.lnk.telstra.net [139.130.54.222])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2KMlAH14010
- for
; Tue, 20 Mar 2001 17:47:11 -0500 (EST)-Received: from oberon (Oberon.rime.com.au [203.8.195.100])
- by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id JAA06895;
- Wed, 21 Mar 2001 09:46:55 +1100
-X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
-Date: Wed, 21 Mar 2001 09:46:55 +1100
-To: Christopher Sawtell ,
-Subject: Re: [HACKERS] More on elog and error codes
-In-Reply-To: <01032109414401.09393@berty>
-Mime-Version: 1.0
-Content-Type: text/plain; charset="us-ascii"
-Precedence: bulk
-Status: OR
-
-At 09:41 21/03/01 +1200, Christopher Sawtell wrote:
->Just that it might be a good idea to incorporate the version / release
->details in some way so that when somebody on the list is squeaking about
->an error message it is obvious to the helper that the advice needed is to
->upgrade from the Cretatious Period version to a modern release, and have
->another go.
-
-This is better handled by the bug *reporting* system; the users can easily
-get the current version number from PG and send it with their reports. We
-don't really want all the error codes changing between releases.
-
-
-----------------------------------------------------------------
-Philip Warner | __---_____
-Albatross Consulting Pty. Ltd. |----/ - \
-(A.B.N. 75 008 659 498) | /(@) ______---_
-Tel: (+61) 0500 83 82 81 | _________ \
-Fax: (+61) 0500 83 82 82 | ___________ |
-Http://www.rhyme.com.au | / \|
- | --________--
-PGP key available upon request, | /
-and from pgp5.ai.mit.edu:11371 |/
-
----------------------------(end of broadcast)---------------------------
-TIP 2: you can get off all lists at once with the unregister command
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id VAA14475
- for
; Tue, 20 Mar 2001 21:47:11 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2L2jHH28234;
- Tue, 20 Mar 2001 21:45:17 -0500 (EST)
-Received: from acheron.rime.com.au (albatr.lnk.telstra.net [139.130.54.222])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2L2hcH27912
- for
; Tue, 20 Mar 2001 21:43:38 -0500 (EST)-Received: from oberon (Oberon.rime.com.au [203.8.195.100])
- by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id NAA10433;
- Wed, 21 Mar 2001 13:43:25 +1100
-X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
-Date: Wed, 21 Mar 2001 13:43:25 +1100
-Subject: Re: [HACKERS] More on elog and error codes
-Cc: PostgreSQL Development
-Mime-Version: 1.0
-Content-Type: text/plain; charset="us-ascii"
-Precedence: bulk
-Status: OR
-
-At 09:43 21/03/01 +1100, Philip Warner wrote:
->
->Code SQL Text
->PGERR_TYPALREXI 02xxx "type %s cannot be created because it already exists"
->PGERR_FUNCNOTYPE 02xxx "type %s used as argument %d of function %s doesn't
->exist"
->
-
-Peter,
-
-Just to clarify, because in a previous email you seemed to believe that I
-wanted 'PGERR_TYPALREXI' to resolve to a string. I have no such desire; a
-meaningful number is fine, but we should never have to type it. One
-possibility is that it is the address of an error-info function (built by
-'compiling' the message file). Another possibility is that it could be a
-prefix to several external symbols, PGERR_TYPALREXI_msg,
-PGERR_TYPALREXI_code, PGERR_TYPALREXI_num, PGERR_TYPALREXI_sqlcode etc,
-which are again built by compiling the message file. We can then encode
-whatever we like into the message, have flexible text, and ease of use for
-developers.
-
-Hope this clarifies things...
-
-
-
-
-----------------------------------------------------------------
-Philip Warner | __---_____
-Albatross Consulting Pty. Ltd. |----/ - \
-(A.B.N. 75 008 659 498) | /(@) ______---_
-Tel: (+61) 0500 83 82 81 | _________ \
-Fax: (+61) 0500 83 82 82 | ___________ |
-Http://www.rhyme.com.au | / \|
- | --________--
-PGP key available upon request, | /
-and from pgp5.ai.mit.edu:11371 |/
-
----------------------------(end of broadcast)---------------------------
-TIP 2: you can get off all lists at once with the unregister command
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id PAA13050
- for
; Wed, 21 Mar 2001 15:54:59 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2LKsCt45782;
- Wed, 21 Mar 2001 15:54:12 -0500 (EST)
-Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2LKrst45607
- for
; Wed, 21 Mar 2001 15:53:54 -0500 (EST)-Received: from fwd07.sul.t-online.com
- by mailout01.sul.t-online.com with smtp
- id 14fpbU-0001v6-04; Wed, 21 Mar 2001 21:53:12 +0100
-Received: from peter.localdomain (520083510237-0001@[212.185.245.125]) by fmrl07.sul.t-online.com
- with esmtp id 14fpbH-25w9q4C; Wed, 21 Mar 2001 21:52:59 +0100
-Date: Wed, 21 Mar 2001 22:03:09 +0100 (CET)
-cc: PostgreSQL Development
-Subject: Re: [HACKERS] More on elog and error codes
-MIME-Version: 1.0
-Content-Type: TEXT/PLAIN; charset=US-ASCII
-Precedence: bulk
-Status: OR
-
-Philip Warner writes:
-
-> If the motivation behind this is to alloy easy translation to SQL error
-> codes, then I suggest we have an error definition file with explicit
-> translation:
->
-> Code SQL Text
-> PGERR_TYPALREXI 02xxx "type %s cannot be created because it already exists"
-> PGERR_FUNCNOTYPE 02xxx "type %s used as argument %d of function %s doesn't
-> exist"
->
-> and if we want a generic 'type does not exist', then:
->
-> PGERR_NOSUCHTYPE 02xxx "type %s does not exist - %s"
->
-> where the %s might contain 'it can't be used as a function argument'.
->
-> the we just have
->
-> elogc(ERROR, PGERR_TYPALEXI, ...)
->
-> /* elsewhere... */
->
-> elogc(ERROR, PGERR_FUNCNOTYPE, ...)
-
-This is going to be a disaster for the coder. Every time you look at an
-elog you don't know what it does? Is the first arg a %s or a %d? What's
-the first %s, what the second? How can this be checked against bugs? (I
-know GCC can be pretty helpful here, but does it catch all problems?)
-
-Conversely, when you look at the error message you don't know from what
-contexts it's called. The error messages will degrade rapidly in quality
-because changing one will become a major project.
-
-> Creating central message files/objects has the added advantage of a much
-> simpler locale support - they're just resource files, and they're NOT
-> embedded throughout the code.
-
-Actually, the fact that the messages are in the code, where they're used,
-and not in a catalog file is a reason why gettext is so popular and
-catgets gets laughed at.
-
---
-
-
----------------------------(end of broadcast)---------------------------
-TIP 3: if posting/reading through Usenet, please send an appropriate
-message can get through to the mailing list cleanly
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id UAA03400
- for
; Wed, 21 Mar 2001 20:32:02 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2M1VSt53916;
- Wed, 21 Mar 2001 20:31:28 -0500 (EST)
-Received: from acheron.rime.com.au (albatr.lnk.telstra.net [139.130.54.222])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2M1UZt53760
- for
; Wed, 21 Mar 2001 20:30:36 -0500 (EST)-Received: from oberon (Oberon.rime.com.au [203.8.195.100])
- by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id MAA11046;
- Thu, 22 Mar 2001 12:30:19 +1100
-X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
-Date: Thu, 22 Mar 2001 12:30:19 +1100
-Subject: Re: [HACKERS] More on elog and error codes
-Cc: PostgreSQL Development
-Mime-Version: 1.0
-Content-Type: text/plain; charset="us-ascii"
-Precedence: bulk
-Status: OR
-
-At 22:03 21/03/01 +0100, Peter Eisentraut wrote:
->Philip Warner writes:
->
->> If the motivation behind this is to alloy easy translation to SQL error
->> codes, then I suggest we have an error definition file with explicit
->> translation:
->>
->> Code SQL Text
->> PGERR_TYPALREXI 02xxx "type %s cannot be created because it already
-exists"
->> PGERR_FUNCNOTYPE 02xxx "type %s used as argument %d of function %s doesn't
->> exist"
->>
->> and if we want a generic 'type does not exist', then:
->>
->> PGERR_NOSUCHTYPE 02xxx "type %s does not exist - %s"
->>
->> where the %s might contain 'it can't be used as a function argument'.
->>
->> the we just have
->>
->> elogc(ERROR, PGERR_TYPALEXI, ...)
->>
->> /* elsewhere... */
->>
->> elogc(ERROR, PGERR_FUNCNOTYPE, ...)
->
->This is going to be a disaster for the coder. Every time you look at an
->elog you don't know what it does? Is the first arg a %s or a %d? What's
->the first %s, what the second?
-
->From experience using this sort of system, probably 80% of errors in new
-code are new; if you don't know the format of your own errors, then you
-have a larger problem. Secondly, most errors have obvious parameters, and
-it only ever gets confusing when they have more than one parameter, and
-even then it's pretty obvious. This concern was often raised by people new
-to the system, but generally turned out to be more FUD than fact.
-
-
->How can this be checked against bugs?
->Conversely, when you look at the error message you don't know from what
->contexts it's called.
-
-Am I missing something here? The user gets a message like:
-
- TYPALREXI: Specified type 'fred' already exists.
-
-then we do
-
- glimpse TYPALREXI
-
-It is actually a lot easier than the plain text search we already have to
-do, when we have to guess at the words that have been substituted into the
-message. Besides, in *both* proposed systems, if we have done things
-properly, then the postgres log also contains the module name & line #.
-
-
->The error messages will degrade rapidly in quality
->because changing one will become a major project.
-
-Changing one will be a major project only if it is used everywhere. Most
-will be relatively localized. And, with glimpse 'XYZ', it's not really that
-big a task. Finally, you would need to ask why it was being changed - would
-a new message work better? Tell me where the degradation in quality is in
-comparison with text-in-the-source versions, with umpteen dozen slightly
-different versions of essentially the same error messages?
-
-
->> Creating central message files/objects has the added advantage of a much
->> simpler locale support - they're just resource files, and they're NOT
->> embedded throughout the code.
->
->Actually, the fact that the messages are in the code, where they're used,
->and not in a catalog file is a reason why gettext is so popular and
->catgets gets laughed at.
-
-Is there a URL for a getcats vs. gettext debate would help me understand
-the reason for the laughter? I can understand laughing at code that looks
-like:
-
- elog(ERROR, 123456, typename);
-
-but
-
- elog(ERROR, TYPALREXI, typename);
-
-is a whole lot more readable.
-
-
-Also, you failed to address the two points below:
-
->#define PGERR_TYPE 1854
->
->/* somewhere... */
->
->elogc(ERROR, PGERR_TYPE, "type %s cannot be created because it already
-exists", ...)
->
->/* elsewhere... */
->
->elogc(ERROR, PGERR_TYPE, "type %s used as argument %d of function %s
-doesn't exist", ...)
->
-
-In the specific example above, returning the same error code is not going
-to help the client. What if they want to handle "type %s used as argument
-%d of function %s doesn't exist" by creating the type, and silently ignore
-"type %s cannot be created because it already exists"?
-
-How do you handle "type %s can not be used as a function return type"? Is
-this PGERR_FUNC or PGERR_TYPE?
-
-
-
-----------------------------------------------------------------
-Philip Warner | __---_____
-Albatross Consulting Pty. Ltd. |----/ - \
-(A.B.N. 75 008 659 498) | /(@) ______---_
-Tel: (+61) 0500 83 82 81 | _________ \
-Fax: (+61) 0500 83 82 82 | ___________ |
-Http://www.rhyme.com.au | / \|
- | --________--
-PGP key available upon request, | /
-and from pgp5.ai.mit.edu:11371 |/
-
----------------------------(end of broadcast)---------------------------
-TIP 5: Have you checked our extensive FAQ?
-
-http://www.postgresql.org/users-lounge/docs/faq.html
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id XAA12785
- for
; Wed, 21 Mar 2001 23:27:38 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2M4QOt75962;
- Wed, 21 Mar 2001 23:26:24 -0500 (EST)
-Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2M4PWt75732
- for
; Wed, 21 Mar 2001 23:25:32 -0500 (EST)-Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
- by sss.pgh.pa.us (8.11.1/8.11.1) with ESMTP id f2M4Ov607983;
- Wed, 21 Mar 2001 23:24:57 -0500 (EST)
-Subject: Re: [HACKERS] More on elog and error codes
-Comments: In-reply-to Philip Warner
- message dated "Thu, 22 Mar 2001 12:30:19 +1100"
-Date: Wed, 21 Mar 2001 23:24:57 -0500
-From: Tom Lane
-Precedence: bulk
-Status: OR
-
-I've pretty much got to agree with Peter on both of these points.
-
-> At 22:03 21/03/01 +0100, Peter Eisentraut wrote:
->>>> elogc(ERROR, PGERR_FUNCNOTYPE, ...)
->>
->> This is going to be a disaster for the coder. Every time you look at an
->> elog you don't know what it does? Is the first arg a %s or a %d? What's
->> the first %s, what the second?
-
->> From experience using this sort of system, probably 80% of errors in new
-> code are new; if you don't know the format of your own errors, then you
-> have a larger problem. Secondly, most errors have obvious parameters, and
-> it only ever gets confusing when they have more than one parameter, and
-> even then it's pretty obvious.
-
-The general set of parameters might be pretty obvious, but the exact
-type that the format string expects them to be is not so obvious. We
-have enough ints, longs, unsigned longs, etc etc running around the
-system that care is required. If you look at the existing elog calls
-you'll find quite a lot of explicit casts to make certain that the right
-thing will happen. If the format strings are not directly visible to
-the guy writing an elog call, then errors of that kind will creep in
-more easily.
-
->> The error messages will degrade rapidly in quality
->> because changing one will become a major project.
-
-> Changing one will be a major project only if it is used everywhere.
-
-I agree with Peter on this one too. Even having to edit a separate
-file will create enough friction that people will tend to use an
-existing string if it's even marginally appropriate. What I fear even
-more is that people will simply not code error checks, especially for
-"can't happen" cases, because it's too much of a pain in the neck to
-register the appropriate message.
-
-We must not raise the cost of adding error checks significantly, or we
-will lose the marginal checks that sometimes save our bacon by revealing
-bugs.
-
- regards, tom lane
-
----------------------------(end of broadcast)---------------------------
-TIP 4: Don't 'kill -9' the postmaster
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id XAA13781
- for
; Wed, 21 Mar 2001 23:50:39 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2M4oDt78916;
- Wed, 21 Mar 2001 23:50:13 -0500 (EST)
-Received: from acheron.rime.com.au (albatr.lnk.telstra.net [139.130.54.222])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2M4m9t78519
- for
; Wed, 21 Mar 2001 23:48:09 -0500 (EST)-Received: from oberon (Oberon.rime.com.au [203.8.195.100])
- by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id PAA14815;
- Thu, 22 Mar 2001 15:47:52 +1100
-X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
-Date: Thu, 22 Mar 2001 15:47:52 +1100
-Subject: Re: [HACKERS] More on elog and error codes
-Cc: PostgreSQL Development
-Mime-Version: 1.0
-Content-Type: text/plain; charset="us-ascii"
-Precedence: bulk
-Status: OR
-
-At 22:03 21/03/01 +0100, Peter Eisentraut wrote:
->
->This is going to be a disaster for the coder. Every time you look at an
->elog you don't know what it does? Is the first arg a %s or a %d? What's
->the first %s, what the second?
-
-FWIW, I did a quick scan for elog in PG and found:
-
-- 6856 calls (may include commented-out calls)
-- 2528 unique messages
-- 1248 have no parameters
-- 859 have exactly one argument
-- 285 have exactly 2 args
-- 136 have 3 or more args
-
-so 83% have one or no arguments, which is probably not going to be very
-confusing.
-
-Looking at the actual messages, there is also a great deal of opportunity
-to standardize and simplify since many of the messages only differ by their
-prefixed function name.
-
-
-
-----------------------------------------------------------------
-Philip Warner | __---_____
-Albatross Consulting Pty. Ltd. |----/ - \
-(A.B.N. 75 008 659 498) | /(@) ______---_
-Tel: (+61) 0500 83 82 81 | _________ \
-Fax: (+61) 0500 83 82 82 | ___________ |
-Http://www.rhyme.com.au | / \|
- | --________--
-PGP key available upon request, | /
-and from pgp5.ai.mit.edu:11371 |/
-
----------------------------(end of broadcast)---------------------------
-TIP 3: if posting/reading through Usenet, please send an appropriate
-message can get through to the mailing list cleanly
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id AAA15497
- for
; Thu, 22 Mar 2001 00:21:11 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2M5Kkt84723;
- Thu, 22 Mar 2001 00:20:46 -0500 (EST)
-Received: from acheron.rime.com.au (albatr.lnk.telstra.net [139.130.54.222])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2M5K5t84513
- for
; Thu, 22 Mar 2001 00:20:06 -0500 (EST)-Received: from oberon (Oberon.rime.com.au [203.8.195.100])
- by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id QAA15327;
- Thu, 22 Mar 2001 16:19:38 +1100
-X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
-Date: Thu, 22 Mar 2001 16:19:38 +1100
-To: Tom Lane
-Subject: Re: [HACKERS] More on elog and error codes
-Mime-Version: 1.0
-Content-Type: text/plain; charset="us-ascii"
-Precedence: bulk
-Status: OR
-
-At 23:24 21/03/01 -0500, Tom Lane wrote:
->I've pretty much got to agree with Peter on both of these points.
-
-Damn.
-
-
->> At 22:03 21/03/01 +0100, Peter Eisentraut wrote:
->>>>> elogc(ERROR, PGERR_FUNCNOTYPE, ...)
->>>
->>> This is going to be a disaster for the coder. Every time you look at an
->>> elog you don't know what it does? Is the first arg a %s or a %d? What's
->>> the first %s, what the second?
->
->>> From experience using this sort of system, probably 80% of errors in new
->> code are new; if you don't know the format of your own errors, then you
->> have a larger problem. Secondly, most errors have obvious parameters, and
->> it only ever gets confusing when they have more than one parameter, and
->> even then it's pretty obvious.
->
->The general set of parameters might be pretty obvious, but the exact
->type that the format string expects them to be is not so obvious. We
->have enough ints, longs, unsigned longs, etc etc running around the
->system that care is required. If you look at the existing elog calls
->you'll find quite a lot of explicit casts to make certain that the right
->thing will happen. If the format strings are not directly visible to
->the guy writing an elog call, then errors of that kind will creep in
->more easily.
-
-I agree it's more likely, but most (all?) cases can be caught by the
-compiler. It's not ideal, but neither is having eight different versions of
-the same message.
-
-
->>> The error messages will degrade rapidly in quality
->>> because changing one will become a major project.
->
->> Changing one will be a major project only if it is used everywhere.
->
->I agree with Peter on this one too. Even having to edit a separate
->file will create enough friction that people will tend to use an
->existing string if it's even marginally appropriate. What I fear even
->more is that people will simply not code error checks, especially for
->"can't happen" cases, because it's too much of a pain in the neck to
->register the appropriate message.
->
->We must not raise the cost of adding error checks significantly, or we
->will lose the marginal checks that sometimes save our bacon by revealing
->bugs.
-
-This is a problem, I agree - but a procedural one. We need to make
-registering messages easy. To do this, rather than having a central message
-file, perhaps do the following:
-
-- allow multiple message files (which can be processed to produce .h
-files). eg. pg_dump would have it's own pg_dump_messages.xxx file.
-
-- define a message that will assume it's first arg is really a format
-string for use in the "can't happen" classes, and which has the SQLCODE for
-'internal error'.
-
-We do need some central control, but by creating module-based message files
-we can allocate number ranges easily, and we at least take a step down the
-path towards a both easy locale handling and a 'big book of error codes'.
-
-
-----------------------------------------------------------------
-Philip Warner | __---_____
-Albatross Consulting Pty. Ltd. |----/ - \
-(A.B.N. 75 008 659 498) | /(@) ______---_
-Tel: (+61) 0500 83 82 81 | _________ \
-Fax: (+61) 0500 83 82 82 | ___________ |
-Http://www.rhyme.com.au | / \|
- | --________--
-PGP key available upon request, | /
-and from pgp5.ai.mit.edu:11371 |/
-
----------------------------(end of broadcast)---------------------------
-TIP 5: Have you checked our extensive FAQ?
-
-http://www.postgresql.org/users-lounge/docs/faq.html
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id AAA16152
- for
; Thu, 22 Mar 2001 00:39:33 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2M5d5t87081;
- Thu, 22 Mar 2001 00:39:06 -0500 (EST)
-Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2M5aCt86851
- for
; Thu, 22 Mar 2001 00:36:12 -0500 (EST)-Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
- by sss.pgh.pa.us (8.11.1/8.11.1) with ESMTP id f2M5Zm618634;
- Thu, 22 Mar 2001 00:35:48 -0500 (EST)
-Subject: Re: [HACKERS] More on elog and error codes
-Comments: In-reply-to Philip Warner
- message dated "Thu, 22 Mar 2001 16:19:38 +1100"
-Date: Thu, 22 Mar 2001 00:35:48 -0500
-From: Tom Lane
-Precedence: bulk
-Status: OR
-
-> This is a problem, I agree - but a procedural one. We need to make
-> registering messages easy. To do this, rather than having a central message
-> file, perhaps do the following:
-
-> - allow multiple message files (which can be processed to produce .h
-> files). eg. pg_dump would have it's own pg_dump_messages.xxx file.
-
-I guess I fail to see why that's better than processing the .c files
-to extract the message strings from them.
-
-I agree that the sort of system Peter proposes doesn't have any direct
-forcing function to discourage gratuitous variations of what's basically
-the same message. The forcing function would have to come from the
-translators, who will look at the extracted list of messages and
-complain that there are near-duplicates. Then we fix the
-near-duplicates. Seems like no big deal.
-
-However, a system that uses multiple message files is also not going to
-discourage near-duplicates very effectively. I don't think you can have
-it both ways: if you are discouraging near-duplicates, then you are
-making it harder to for people to create new messages, whether
-duplicates or not.
-
- regards, tom lane
-
----------------------------(end of broadcast)---------------------------
-TIP 5: Have you checked our extensive FAQ?
-
-http://www.postgresql.org/users-lounge/docs/faq.html
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id BAA20802
- for
; Thu, 22 Mar 2001 01:42:23 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2M6g2t94104;
- Thu, 22 Mar 2001 01:42:02 -0500 (EST)
-Received: from acheron.rime.com.au (albatr.lnk.telstra.net [139.130.54.222])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2M6eut94000
- for
; Thu, 22 Mar 2001 01:40:57 -0500 (EST)-Received: from oberon (Oberon.rime.com.au [203.8.195.100])
- by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id RAA16408;
- Thu, 22 Mar 2001 17:40:23 +1100
-X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
-Date: Thu, 22 Mar 2001 17:40:22 +1100
-To: Tom Lane
-Subject: Re: [HACKERS] More on elog and error codes
-Mime-Version: 1.0
-Content-Type: text/plain; charset="us-ascii"
-Precedence: bulk
-Status: OR
-
-At 00:35 22/03/01 -0500, Tom Lane wrote:
->> This is a problem, I agree - but a procedural one. We need to make
->> registering messages easy. To do this, rather than having a central message
->> file, perhaps do the following:
->
->> - allow multiple message files (which can be processed to produce .h
->> files). eg. pg_dump would have it's own pg_dump_messages.xxx file.
->
->However, a system that uses multiple message files is also not going to
->discourage near-duplicates very effectively. I don't think you can have
->it both ways: if you are discouraging near-duplicates, then you are
->making it harder to for people to create new messages, whether
->duplicates or not.
-
-Many of the near duplicates are in the same, or related, code so with local
-message files there should be a good chance of reduced duplicates.
-
-Other advantages of a separate definition include:
-
-- Extra fields (eg. description, resolution) which could be used by client
-programs.
-- Message IDs which can be checked by clients to detect specific errors,
-independent of locale.
-- SQLCODE set in one place, rather than developers having to code it in
-multiple places.
-
-The original proposal also included a 'class' field:
-
- elogc(ERROR, PGERR_TYPE, "type %s cannot be created because it already
-
-ISTM that we will have a similar allocation problem with these. But, more
-recent example have exluded them, so I am not sure about their status is
-Peter's plans.
-
-
-
-
-----------------------------------------------------------------
-Philip Warner | __---_____
-Albatross Consulting Pty. Ltd. |----/ - \
-(A.B.N. 75 008 659 498) | /(@) ______---_
-Tel: (+61) 0500 83 82 81 | _________ \
-Fax: (+61) 0500 83 82 82 | ___________ |
-Http://www.rhyme.com.au | / \|
- | --________--
-PGP key available upon request, | /
-and from pgp5.ai.mit.edu:11371 |/
-
----------------------------(end of broadcast)---------------------------
-TIP 5: Have you checked our extensive FAQ?
-
-http://www.postgresql.org/users-lounge/docs/faq.html
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id SAA09636
- for
; Mon, 19 Mar 2001 18:04:15 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2JN3VN17922;
- Mon, 19 Mar 2001 18:03:31 -0500 (EST)
-Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2JN0nN17660
- for
; Mon, 19 Mar 2001 18:00:49 -0500 (EST)-Received: from fwd03.sul.t-online.com
- by mailout02.sul.t-online.com with smtp
- id 14f8dr-0005W0-04; Tue, 20 Mar 2001 00:00:47 +0100
-Received: from peter.localdomain (520083510237-0001@[217.80.146.106]) by fmrl03.sul.t-online.com
- with esmtp id 14f8dg-26MpaCC; Tue, 20 Mar 2001 00:00:36 +0100
-Date: Tue, 20 Mar 2001 00:10:43 +0100 (CET)
-To: PostgreSQL Development
-Subject: [HACKERS] elog with automatic file, line, and function
-MIME-Version: 1.0
-Content-Type: TEXT/PLAIN; charset=US-ASCII
-Precedence: bulk
-Status: OR
-
-It has been brought up that elog should be able to automatically fill in
-the file, line, and perhaps the function name where it's called, to avoid
-having to prefix each message with the function name by hand, which is
-quite ugly.
-
-This is doable, but it requires a C preprocessor that can handle varargs
-macros. Since this is required by C99 and has been available in GCC for a
-while, it *might* be okay to rely on this.
-
-Additionally, C99 (and GCC for a while) would allow filling in the
-function name automatically.
-
-Since these would be mostly developer features, how do people feel about
-relying on modern tools for implementing these? The bottom line seems to
-be that without these tools it would simply not be possible.
-
---
-
-
----------------------------(end of broadcast)---------------------------
-TIP 2: you can get off all lists at once with the unregister command
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id SAA10579
- for
; Mon, 19 Mar 2001 18:26:29 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2JNQ1N53252;
- Mon, 19 Mar 2001 18:26:01 -0500 (EST)
-Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2JNNXN45362
- for
; Mon, 19 Mar 2001 18:23:33 -0500 (EST)-Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
- by sss.pgh.pa.us (8.11.1/8.11.1) with ESMTP id f2JNNUt07935;
- Mon, 19 Mar 2001 18:23:30 -0500 (EST)
-cc: PostgreSQL Development
-Subject: Re: [HACKERS] elog with automatic file, line, and function
-Comments: In-reply-to Peter Eisentraut
- message dated "Tue, 20 Mar 2001 00:10:43 +0100"
-Date: Mon, 19 Mar 2001 18:23:30 -0500
-From: Tom Lane
-Precedence: bulk
-Status: OR
-
-Peter Eisentraut
writes:-> It has been brought up that elog should be able to automatically fill in
-> the file, line, and perhaps the function name where it's called, to avoid
-> having to prefix each message with the function name by hand, which is
-> quite ugly.
-
-> Since these would be mostly developer features, how do people feel about
-> relying on modern tools for implementing these?
-
-Not happy. A primary reason for wanting the exact location is to make
-bug reports more specific. If Joe User's copy of Postgres doesn't
-report error location then it doesn't help me much that my copy does
-(if I could reproduce the reported failure, then gdb will tell me where
-the elog call is...). In particular, we *cannot* remove the habit of
-mentioning the reporting routine name in the message text unless there
-is an adequate substitute in all builds.
-
-> The bottom line seems to be that without these tools it would simply
-> not be possible.
-
-Sure it is, it just requires a marginal increase in ugliness, namely
-double parentheses:
-
- ELOG((level, format, arg1, arg2, ...))
-
-which might work like
-
-#define ELOG(ARGS) (elog_setloc(__FILE__, __LINE__), elog ARGS)
-
-
-> Additionally, C99 (and GCC for a while) would allow filling in the
-> function name automatically.
-
-We could probably treat the function name as something that's optionally
-added to the file/line error report info if the compiler supports it.
-
-BTW, how does that work exactly? I assume it can't be a macro ...
-
- regards, tom lane
-
----------------------------(end of broadcast)---------------------------
-TIP 3: if posting/reading through Usenet, please send an appropriate
-message can get through to the mailing list cleanly
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id TAA15096
- for
; Mon, 19 Mar 2001 19:34:33 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2K0Y3N60007;
- Mon, 19 Mar 2001 19:34:03 -0500 (EST)
-Received: from foghorn.airs.com (foghorn.airs.com [63.201.54.26])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2K0XZN59897
- for
; Mon, 19 Mar 2001 19:33:35 -0500 (EST)-Received: (qmail 8819 invoked by uid 10); 20 Mar 2001 00:33:32 -0000
-Received: (qmail 1971 invoked by uid 269); 20 Mar 2001 00:33:28 -0000
-To: Tom Lane
-Subject: Re: [HACKERS] elog with automatic file, line, and function
-From: Ian Lance Taylor
-Date: 19 Mar 2001 16:33:28 -0800
-In-Reply-To: Tom Lane's message of "Mon, 19 Mar 2001 18:23:30 -0500"
-Message-ID:
-Lines: 17
-User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7
-MIME-Version: 1.0
-Content-Type: text/plain; charset=us-ascii
-Precedence: bulk
-Status: OR
-
-Tom Lane writes:
-
-> > Additionally, C99 (and GCC for a while) would allow filling in the
-> > function name automatically.
->
-> We could probably treat the function name as something that's optionally
-> added to the file/line error report info if the compiler supports it.
->
-> BTW, how does that work exactly? I assume it can't be a macro ...
-
-It's a macro just like __FILE__ and __LINE__ are macros.
-
-gcc has supported __FUNCTION__ and __PRETTY_FUNCTION__ for a long time
-(the latter is the demangled version of the function name when using
-C++).
-
-Ian
-
----------------------------(end of broadcast)---------------------------
-TIP 4: Don't 'kill -9' the postmaster
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id UAA15947
- for
; Mon, 19 Mar 2001 20:00:24 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2K0xjN63216;
- Mon, 19 Mar 2001 19:59:45 -0500 (EST)
-Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2K0ciN60815
- for
; Mon, 19 Mar 2001 19:38:44 -0500 (EST)-Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
- by sss.pgh.pa.us (8.11.1/8.11.1) with ESMTP id f2K0cbt08356;
- Mon, 19 Mar 2001 19:38:37 -0500 (EST)
-To: Ian Lance Taylor
-Subject: Re: [HACKERS] elog with automatic file, line, and function
-In-reply-to:
-Comments: In-reply-to Ian Lance Taylor
- message dated "19 Mar 2001 16:33:28 -0800"
-Date: Mon, 19 Mar 2001 19:38:36 -0500
-From: Tom Lane
-Precedence: bulk
-Status: OR
-
-Ian Lance Taylor writes:
-> Tom Lane writes:
->> BTW, how does that work exactly? I assume it can't be a macro ...
-
-> It's a macro just like __FILE__ and __LINE__ are macros.
-
-> gcc has supported __FUNCTION__ and __PRETTY_FUNCTION__ for a long time
-> (the latter is the demangled version of the function name when using
-> C++).
-
-Now that I know the name, I can find it in the gcc docs, which clearly
-explain that these names are not macros ;-). The preprocessor would
-have a tough time making such a substitution.
-
-However, if the C99 spec has such a concept, they didn't use that name
-for it ...
-
- regards, tom lane
-
----------------------------(end of broadcast)---------------------------
-TIP 3: if posting/reading through Usenet, please send an appropriate
-message can get through to the mailing list cleanly
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id UAA16850
- for
; Mon, 19 Mar 2001 20:29:45 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2K1T5N83769;
- Mon, 19 Mar 2001 20:29:05 -0500 (EST)
-Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2K1PrN75990
- for
; Mon, 19 Mar 2001 20:25:53 -0500 (EST)-Received: (from ler@localhost)
- by lerami.lerctr.org (8.12.0.Beta5/8.12.0.Beta5/20010318/$Revision: 1.1 $) id f2K1Pm1K029350;
- Mon, 19 Mar 2001 19:25:48 -0600 (CST)
- (envelope-from ler)
-Date: Mon, 19 Mar 2001 19:25:48 -0600
-From: Larry Rosenman
-To: Tom Lane
-Cc: Ian Lance Taylor
, Peter Eisentraut ,-Subject: Re: [HACKERS] elog with automatic file, line, and function
-Mime-Version: 1.0
-Content-Type: text/plain; charset=us-ascii
-Content-Disposition: inline
-User-Agent: Mutt/1.3.16i
-X-Mailer: Mutt http://www.mutt.org/
-Precedence: bulk
-Status: OR
-
-* Tom Lane [010319 18:58]:
-> Ian Lance Taylor writes:
-> > Tom Lane writes:
-> >> BTW, how does that work exactly? I assume it can't be a macro ...
->
-> > It's a macro just like __FILE__ and __LINE__ are macros.
->
-> > gcc has supported __FUNCTION__ and __PRETTY_FUNCTION__ for a long time
-> > (the latter is the demangled version of the function name when using
-> > C++).
->
-> Now that I know the name, I can find it in the gcc docs, which clearly
-> explain that these names are not macros ;-). The preprocessor would
-> have a tough time making such a substitution.
->
-> However, if the C99 spec has such a concept, they didn't use that name
-> for it ...
-My C99 compiler (SCO, UDK FS 7.1.1b), defines the following:
-Predefined names
-
-The following identifiers are predefined as object-like macros:
-
-
-__LINE__
- The current line number as a decimal constant.
-
-__FILE__
- A string literal representing the name of the file being compiled.
-
-__DATE__
- The date of compilation as a string literal in the form ``Mmm dd
-yyyy.''
-
-__TIME__
- The time of compilation, as a string literal in the form
-``hh:mm:ss.''
-
-__STDC__
- The constant 1 under compilation mode -Xc, otherwise 0.
-
-__USLC__
- A positive integer constant; its definition signifies a USL C
-compilation system.
-
-Nothing for function that I can find.
-
-LER
-
->
-> regards, tom lane
->
-> ---------------------------(end of broadcast)---------------------------
-> TIP 3: if posting/reading through Usenet, please send an appropriate
-> message can get through to the mailing list cleanly
---
-Larry Rosenman http://www.lerctr.org/~ler
-US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
-
----------------------------(end of broadcast)---------------------------
-TIP 6: Have you searched our list archives?
-
-http://www.postgresql.org/search.mpl
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id UAA17752
- for
; Mon, 19 Mar 2001 20:49:48 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2K1n8N87285;
- Mon, 19 Mar 2001 20:49:08 -0500 (EST)
-Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2K1iFN86846
- for
; Mon, 19 Mar 2001 20:44:15 -0500 (EST)-Received: from 207-172-137-172.s45.as3.dam.md.dialup.rcn.com (HELO yahoo.com) (207.172.137.172)
- by smtp.mail.vip.sc5.yahoo.com with SMTP; 20 Mar 2001 01:44:11 -0000
-X-Apparently-From:
-Date: Mon, 19 Mar 2001 20:44:11 -0500
-From: Neal Norwitz
-Organization: MetaSlash, Inc.
-X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
-X-Accept-Language: en
-MIME-Version: 1.0
-Subject: Re: [HACKERS] elog with automatic file, line, and function
-Content-Type: text/plain; charset=us-ascii
-Content-Transfer-Encoding: 7bit
-Precedence: bulk
-Status: OR
-
-Peter Eisentraut wrote:
->
-> It has been brought up that elog should be able to automatically fill in
-> the file, line, and perhaps the function name where it's called, to avoid
-> having to prefix each message with the function name by hand, which is
-> quite ugly.
->
-> This is doable, but it requires a C preprocessor that can handle varargs
-> macros. Since this is required by C99 and has been available in GCC for a
-> while, it *might* be okay to rely on this.
->
-> Additionally, C99 (and GCC for a while) would allow filling in the
-> function name automatically.
->
-> Since these would be mostly developer features, how do people feel about
-> relying on modern tools for implementing these? The bottom line seems to
-> be that without these tools it would simply not be possible.
-
-It is possible, however, the macros require an extra set of parentheses:
-
-void elog_internal(const char* file, unsigned long line, ... );
-#define ELOG(args) elog_internal(__FILE__, __LINE__, args)
-
-ELOG(("%s error", string))
-
-For portability to older compilers, you should probably not require C99.
-
-Also, I'm not positive, but I think that varargs are not part of C++
-yet.
-However, they will likely be added (if not already in draft form).
-
-Neal
-
-_________________________________________________________
-Do You Yahoo!?
-Get your free @yahoo.com address at http://mail.yahoo.com
-
-
----------------------------(end of broadcast)---------------------------
-TIP 5: Have you checked our extensive FAQ?
-
-http://www.postgresql.org/users-lounge/docs/faq.html
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id PAA12714
- for
; Wed, 21 Mar 2001 15:48:40 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2LKltt44369;
- Wed, 21 Mar 2001 15:47:55 -0500 (EST)
-Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2LKlCt44260
- for
; Wed, 21 Mar 2001 15:47:13 -0500 (EST)-Received: from fwd01.sul.t-online.com
- by mailout02.sul.t-online.com with smtp
- id 14fpVX-00064K-01; Wed, 21 Mar 2001 21:47:03 +0100
-Received: from peter.localdomain (520083510237-0001@[212.185.245.125]) by fmrl01.sul.t-online.com
- with esmtp id 14fpVN-1fGPi4C; Wed, 21 Mar 2001 21:46:53 +0100
-Date: Wed, 21 Mar 2001 21:57:04 +0100 (CET)
-To: Tom Lane
-cc: PostgreSQL Development
-Subject: Re: [HACKERS] elog with automatic file, line, and function
-MIME-Version: 1.0
-Content-Type: TEXT/PLAIN; charset=US-ASCII
-Precedence: bulk
-Status: OR
-
-Tom Lane writes:
-
-> Sure it is, it just requires a marginal increase in ugliness, namely
-> double parentheses:
->
-> ELOG((level, format, arg1, arg2, ...))
->
-> which might work like
->
-> #define ELOG(ARGS) (elog_setloc(__FILE__, __LINE__), elog ARGS)
-
-Would the first function save the data in global variables?
-
---
-
-
----------------------------(end of broadcast)---------------------------
-TIP 6: Have you searched our list archives?
-
-http://www.postgresql.org/search.mpl
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id VAA28552
- for
; Wed, 21 Mar 2001 21:55:11 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2M2slt64569;
- Wed, 21 Mar 2001 21:54:47 -0500 (EST)
-Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2M2sSt64463
- for
; Wed, 21 Mar 2001 21:54:28 -0500 (EST)-Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
- by sss.pgh.pa.us (8.11.1/8.11.1) with ESMTP id f2M2sN602818;
- Wed, 21 Mar 2001 21:54:23 -0500 (EST)
-cc: PostgreSQL Development
-Subject: Re: [HACKERS] elog with automatic file, line, and function
-Comments: In-reply-to Peter Eisentraut
- message dated "Wed, 21 Mar 2001 21:57:04 +0100"
-Date: Wed, 21 Mar 2001 21:54:23 -0500
-From: Tom Lane
-Precedence: bulk
-Status: OR
-
-Peter Eisentraut
writes:-> Tom Lane writes:
->> #define ELOG(ARGS) (elog_setloc(__FILE__, __LINE__), elog ARGS)
-
-> Would the first function save the data in global variables?
-
-Yes, that's what I was envisioning. Not a super clean solution,
-but workable, and better than requiring varargs macros.
-
- regards, tom lane
-
----------------------------(end of broadcast)---------------------------
-TIP 3: if posting/reading through Usenet, please send an appropriate
-message can get through to the mailing list cleanly
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id LAA01567
- for
; Tue, 20 Mar 2001 11:55:39 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2KGseN34601;
- Tue, 20 Mar 2001 11:54:40 -0500 (EST)
-Received: from reorxrsm.server.lan.at (zep3.it-austria.net [213.150.1.73])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2KGsFN34478
- for
; Tue, 20 Mar 2001 11:54:16 -0500 (EST)-Received: from gz0153.gc.spardat.at (gz0153.gc.spardat.at [172.20.10.149])
- by reorxrsm.server.lan.at (8.11.2/8.11.2) with ESMTP id f2KGs5T20888
- for
; Tue, 20 Mar 2001 17:54:05 +0100-Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service (5.5.2650.21)
- id ; Tue, 20 Mar 2001 17:53:58 +0100
-Message-ID: <11C1E6749A55D411A9670001FA687963368256@sdexcsrv1.f000.d0188.sd.spardat.at>
-From: Zeugswetter Andreas SB
-To: "'Peter Eisentraut'"
, Philip Warner -Cc: PostgreSQL Development
-Subject: AW: [HACKERS] More on elog and error codes
-Date: Tue, 20 Mar 2001 17:53:47 +0100
-MIME-Version: 1.0
-X-Mailer: Internet Mail Service (5.5.2650.21)
-Content-Type: text/plain;
- charset="ISO-8859-1"
-Precedence: bulk
-Status: OR
-
-> #define PGERR_TYPE 1854
-
-#define PGSQLSTATE_TYPE "S0021" // char(5) SQLSTATE
-
-The standard calls this error variable SQLSTATE
-(look up in ESQL standard)
-
-first 2 chars are class next 3 are subclass
-
-"00000" is e.g. Success
-"02000" is Data not found
-"U0xxx" user defined routine error xxx is user defined
-
-> /* somewhere... */
->
-> elogc(ERROR, PGERR_TYPE, "type %s cannot be created because it already exists", ...)
-
-PGELOG(ERROR, PGSQLSTATE_TYPE, ("type %s cannot be created because it already exists", ...))
-
-put varargs into parentheses to avoid need for ... macros see Tom's proposal
-
-I also agree, that we can group different text messages into the same SQLSTATE,
-if it seems appropriate for the client to handle them alike.
-
-Andreas
-
----------------------------(end of broadcast)---------------------------
-TIP 2: you can get off all lists at once with the unregister command
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id MAA03977
- for
; Tue, 20 Mar 2001 12:35:32 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2KHXTN82858;
- Tue, 20 Mar 2001 12:33:29 -0500 (EST)
-Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2KHTsN75514
- for
; Tue, 20 Mar 2001 12:29:54 -0500 (EST)-Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
- by sss.pgh.pa.us (8.11.1/8.11.1) with ESMTP id f2KHTdt11501;
- Tue, 20 Mar 2001 12:29:39 -0500 (EST)
-To: Zeugswetter Andreas SB
-cc: "'Peter Eisentraut'"
, Philip Warner ,-Subject: Re: AW: [HACKERS] More on elog and error codes
-In-reply-to: <11C1E6749A55D411A9670001FA687963368256@sdexcsrv1.f000.d0188.sd.spardat.at>
-References: <11C1E6749A55D411A9670001FA687963368256@sdexcsrv1.f000.d0188.sd.spardat.at>
-Comments: In-reply-to Zeugswetter Andreas SB
- message dated "Tue, 20 Mar 2001 17:53:47 +0100"
-Date: Tue, 20 Mar 2001 12:29:38 -0500
-From: Tom Lane
-Precedence: bulk
-Status: OR
-
-Zeugswetter Andreas SB writes:
-> PGELOG(ERROR, PGSQLSTATE_TYPE, ("type %s cannot be created because it already exists", ...))
-
-> put varargs into parentheses to avoid need for ... macros see Tom's proposal
-
-I'd be inclined to make it
-
-PGELOG((ERROR, PGSQLSTATE_TYPE, "type %s cannot be created because it already exists", ...))
-
-The extra parens are ugly and annoying in any case, but they seem
-slightly less so if you just double the parens associated with the
-PGELOG call. Takes less thought than adding a paren somewhere in the
-middle of the call. IMHO anyway...
-
- regards, tom lane
-
----------------------------(end of broadcast)---------------------------
-TIP 2: you can get off all lists at once with the unregister command
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id LAA01976
- for
; Tue, 20 Mar 2001 11:59:14 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2KGwMN35326;
- Tue, 20 Mar 2001 11:58:22 -0500 (EST)
-Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2KGvjN35102
- for
; Tue, 20 Mar 2001 11:57:45 -0500 (EST)-Received: from ler-freebie.iadfw.net (ler-freebie.iadfw.net [206.66.13.221])
- by lerami.lerctr.org (8.12.0.Beta5/8.12.0.Beta5/20010318/$Revision: 1.1 $) with SMTP id f2KGvcOh016935;
- Tue, 20 Mar 2001 10:57:38 -0600 (CST)
-From: Larry Rosenman
-Date: Tue, 20 Mar 2001 16:57:38 GMT
-Subject: Re: AW: [HACKERS] Re: More on elog and error codes
-CC: Zeugswetter Andreas SB ,
- =?US-ASCII?Q?=27lockhart=40fourpalms=2Eorg=27?= ,
- =?US-ASCII?Q?PostgreSQL?= Development
-X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.2; Linux)
-X-Priority: 3 (Normal)
-MIME-Version: 1.0
-Content-Type: text/plain; charset=ISO-8859-1
-Content-Transfer-Encoding: 8bit
-X-MIME-Autoconverted: from quoted-printable to 8bit by mail.postgresql.org id f2KGvkN35103
-Precedence: bulk
-Status: OR
-
-Coming from an IBM Mainframe background, I'm used to ALL OS/Product
-messages having a message number, and a fat messages and codes book.
-
-I hope we can do that eventually.
-(maybe a database of the error numbers and codes?)
-
-LER
-
-
->>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
-
-On 3/20/01, 10:53:42 AM, Peter Eisentraut
wrote regarding -Re: AW: [HACKERS] Re: More on elog and error codes:
-
-
-> Zeugswetter Andreas SB writes:
-
-> > > SQL9x specifies some error codes, with no particular numbering scheme
-> > > other than negative numbers indicate a problem afaicr.
-> > >
-> > > Shouldn't we map to those where possible?
-> >
-> > Yes, it defines at least a few dozen char(5) error codes. These are
-hierarchical,
-> > grouped into Warnings and Errors, and have room for implementation
-specific
-> > message codes.
-
-> Let's use those then to start with.
-
-> Anyone got a good idea for a client API to this? I think we could just
-> prefix the actual message with the error code, at least as a start.
-> Since they're all fixed width the client could take them apart easily. I
-> recall other RDBMS' (Oracle?) also having an error code before each
-> message.
-
-> --
-
-
-> ---------------------------(end of broadcast)---------------------------
-> TIP 5: Have you checked our extensive FAQ?
-
-> http://www.postgresql.org/users-lounge/docs/faq.html
-
----------------------------(end of broadcast)---------------------------
-TIP 2: you can get off all lists at once with the unregister command
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id RAA23987
- for
; Tue, 20 Mar 2001 17:10:47 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2KMAAH07636;
- Tue, 20 Mar 2001 17:10:10 -0500 (EST)
-Received: from mail.olabinc.com (mail.olabinc.com [63.102.247.99])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2KM88H07164
- for
; Tue, 20 Mar 2001 17:08:09 -0500 (EST)-Received: (from mail@localhost)
- by mail.olabinc.com (8.9.3/8.9.3) id OAA02920
- for
; Tue, 20 Mar 2001 14:18:21 -0800 (PST)-X-Authentication-Warning: mail.olabinc.com: mail set sender to using -f
-Received: from xcdt.olabinc.com(63.102.247.123) by mail.olabinc.com via smap (V2.0)
- id xma002916; Tue, 20 Mar 01 14:18:10 -0800
-Reply-To:
-From: "Otto A. Hirr, Jr."
-To: "PostgreSQL Development"
-Subject: [HACKERS] RE: Re: More on elog and error codes
-Date: Tue, 20 Mar 2001 13:48:49 -0800
-MIME-Version: 1.0
-Content-Type: text/plain;
- charset="iso-8859-1"
-Content-Transfer-Encoding: 7bit
-X-Priority: 3 (Normal)
-X-MSMail-Priority: Normal
-X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
-Importance: Normal
-In-Reply-To: <11C1E6749A55D411A9670001FA687963368255@sdexcsrv1.f000.d0188.sd.spardat.at>
-X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
-Precedence: bulk
-Status: OR
-
-> So we need some good error numbering scheme. Any ideas?
-
-I'm a newbie, but have been following dev and have a few comments
-and these are thoughts not criticisms:
-
-1) I've seen a huge mixture of "how to implement" to support some
- desired feature without first knowing "all" of the features that
- are desired. Examination over all of the mailings reveals some
- but not all of possible features you may want to include.
-2) Define what you want to have without worrying about how to do it.
-3) Design something that can implement all of the features.
-4) Reconsider design if there are performance issues.
-
-e.g.
-
-Features desired
-* system
-* subsystem
-* function
-* file, line, etc
-* severity
-* user-ability-to-recover
-* standards conformance - e.g.. SQL std
-* default msg statement
-* locale msg statement lookup mech, os dep or indep (careful here)
-* success/warning/failure
-* semantic taxonomy
-* syntactic taxonomy
-* forced to user, available to api, logging or not, tracing
-* concept of level
-* reports filtering on some attribute
-* interoperation with existing system reports e.g. syslog, event log,...
-* system environment snapshot option
- (e.g. resource low/empty may/should trigger a log of conn cnt,
- sys resource counts, load, etc)
-* non-mnemonic internal numbers (mnemonic only to obey stds and then
- only as a function call, not by implementation)
-* ease of use (i.e. pgsql-dev-hacker use)
-* ease of use (i.e. api development use)
-* ease of use (i.e. rolling into an existing system, e.g. during
- transition both may need to be in use.)
-* ease of use (i.e. looking through existing errors to find one
- that may "correctly" fit the situation, instead of
- creating yet-another-error-message.)
-* ease of use (i.e. maybe having each "sub-system" having its own
- "error domain" but using the same error mechanism)
-* distinction btwn error report, debug report, tracing report, etc
-* separate the concepts of
- - report creation
- - report delivery
- - report reception
- - report interpretation
-* what do other's do, other's as in os, db, middleware, etc
- along with their strong and weak points
-... what else do you want... and lets flesh out the meaning of
-each of these. Then we can go on to a design...
-
-Sorry if this sounds like a lecture.
-
-With regards to mnemonic things - ugh - this is a database.
-I've worked with a LARGE electronics company that had
-10 and 12 digit mnemonic part numbers. The mnemonic-ness
-begins to break down. (So you have a part number of an eprom,
-what is the part number when it is blown - still an eprom?
-how about including the version of the sw on the eprom? is it
-now an assembly? opps that tended to mean multiple parts attached
-together, humm still looks like an eprom?) They have gone through
-a huge transition to move away, as has the industry from mnemonic
-numbers to simply an id number. You look up the id number in a
->database< :-) to find out what it is.
-
-So why not drop the mnemonic concept and apply a function to a
-blackbox dataitem to determine its attribute? But again first
-determine what attributes you want, which are mandatory, optional,
-system supplied (e.g. __LINE__ etc), is it for erroring, tracing,
-debugging, some combo; then the appropriate dataitem can be
-designed and functions defined. Functions (macros) for both the
-report creation, report distribution, report reception, and
-report interpretation. Some other email pointed out that
-there are different people doing different things. Each of these
-people-groups should identify what they need with regards to
-error, debug, tracing reports. Each may have some nuances that
-are not needed elsewhere, but the reporting system should be able
-to support them all.
-
-Ok, so I've got my flame suit on... but I am really trying to give
-an "outsiders" birdseye view of what I've been reading, hopefully
-which may be helpful.
-
-Best regards,
-
-.. Otto
-
-Otto Hirr
-OLAB Inc.
-503 / 617-6595
-
-
----------------------------(end of broadcast)---------------------------
-TIP 2: you can get off all lists at once with the unregister command
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id WAA16697
- for
; Tue, 20 Mar 2001 22:29:16 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2L3SnH40522;
- Tue, 20 Mar 2001 22:28:49 -0500 (EST)
-Received: from golem.fourpalms.org (www.fourpalms.org [64.3.68.148])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2L3SRH40406
- for
; Tue, 20 Mar 2001 22:28:28 -0500 (EST)-Received: from alumni.caltech.edu (localhost.localdomain [127.0.0.1])
- by golem.fourpalms.org (Postfix) with ESMTP
- id 65C4CFEB4; Wed, 21 Mar 2001 03:28:24 +0000 (UTC)
-Date: Wed, 21 Mar 2001 03:28:24 +0000
-From: Thomas Lockhart
-Organization: Yes
-X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17-21mdksmp i686)
-X-Accept-Language: en
-MIME-Version: 1.0
-Subject: [HACKERS] Re: More on elog and error codes
-Content-Type: text/plain; charset=us-ascii
-Content-Transfer-Encoding: 7bit
-Precedence: bulk
-Status: OR
-
-> Creating central message files/objects has the added advantage of a much
-> simpler locale support - they're just resource files, and they're NOT
-> embedded throughout the code.
-> Finally, if you do want to have some kind of error classification beyond
-> the SQL code, it could be encoded in the error message file.
-
-We could also (automatically) build a DBMS reference table *from* this
-message file (or files), which would allow lookup of messages from codes
-for applications which are not "message-aware".
-
-Not a requirement, and it does not meet all needs (e.g. you would have
-to be connected to get the messages in that case) but it would be
-helpful for some use cases...
-
- - Thomas
-
----------------------------(end of broadcast)---------------------------
-
-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id WAA17120
- for
; Tue, 20 Mar 2001 22:40:58 -0500 (EST)-Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
- by mail.postgresql.org (8.11.3/8.11.1) with SMTP id f2L3dFH41288;
- Tue, 20 Mar 2001 22:39:15 -0500 (EST)
-Received: from acheron.rime.com.au (albatr.lnk.telstra.net [139.130.54.222])
- by mail.postgresql.org (8.11.3/8.11.1) with ESMTP id f2L3caH41183
- for
; Tue, 20 Mar 2001 22:38:36 -0500 (EST)-Received: from oberon (Oberon.rime.com.au [203.8.195.100])
- by acheron.rime.com.au (8.9.3/8.9.3) with SMTP id OAA11228;
- Wed, 21 Mar 2001 14:38:20 +1100
-X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
-Date: Wed, 21 Mar 2001 14:38:21 +1100
-Subject: [HACKERS] Re: More on elog and error codes
-Mime-Version: 1.0
-Content-Type: text/plain; charset="us-ascii"
-Precedence: bulk
-Status: OR
-
-At 03:28 21/03/01 +0000, Thomas Lockhart wrote:
->> Creating central message files/objects has the added advantage of a much
->> simpler locale support - they're just resource files, and they're NOT
->> embedded throughout the code.
->> Finally, if you do want to have some kind of error classification beyond
->> the SQL code, it could be encoded in the error message file.
->
->We could also (automatically) build a DBMS reference table *from* this
->message file (or files), which would allow lookup of messages from codes
->for applications which are not "message-aware".
->
->Not a requirement, and it does not meet all needs (e.g. you would have
->to be connected to get the messages in that case) but it would be
->helpful for some use cases...
-
-If we extended the message definitions to have (optional) description &
-user-resolution sections, then we have the possibilty of asking psql to
-explain the last error, and (broadly) how to fix it. Of course, in the
-first pass, these would all be empty.
-
-
-
-
-----------------------------------------------------------------
-Philip Warner | __---_____
-Albatross Consulting Pty. Ltd. |----/ - \
-(A.B.N. 75 008 659 498) | /(@) ______---_
-Tel: (+61) 0500 83 82 81 | _________ \
-Fax: (+61) 0500 83 82 82 | ___________ |
-Http://www.rhyme.com.au | / \|
- | --________--
-PGP key available upon request, | /
-and from pgp5.ai.mit.edu:11371 |/
-
----------------------------(end of broadcast)---------------------------
-
projects / postgresql.git / commitdiff