diff --git a/doc/TODO.detail/elog b/doc/TODO.detail/elog new file mode 100644 index 0000000000000000000000000000000000000000..7a35a488870af32b15151047da773209c532aeac --- /dev/null +++ b/doc/TODO.detail/elog @@ -0,0 +1,3961 @@ +From pgsql-hackers-owner+M5631@postgresql.org Thu Mar 8 21:04:12 2001 +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) + (envelope-from pgsql-hackers-owner+M5631@postgresql.org) +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) + (envelope-from tgl@sss.pgh.pa.us) +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) +To: pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Internationalized error messages +In-reply-to: <20010308164222.Y624@store.zembu.com> +References: <20010308164222.Y624@store.zembu.com> +Comments: In-reply-to ncm@zembu.com (Nathan Myers) + message dated "Thu, 08 Mar 2001 16:42:22 -0800" +Date: Thu, 08 Mar 2001 21:00:09 -0500 +Message-ID: <4741.984103209@sss.pgh.pa.us> +From: Tom Lane +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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. + +ncm@zembu.com (Nathan Myers) writes: +> 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)--------------------------- +TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org + +From pgsql-hackers-owner+M5633@postgresql.org Thu Mar 8 22:35:37 2001 +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) + (envelope-from pgsql-hackers-owner+M5633@postgresql.org) +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) + (envelope-from ncm@zembu.com) +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 +To: pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Internationalized error messages +Message-ID: <20010308193041.Z624@store.zembu.com> +Reply-To: pgsql-hackers@postgresql.org +References: <20010308164222.Y624@store.zembu.com> <4741.984103209@sss.pgh.pa.us> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +User-Agent: Mutt/1.2.5i +In-Reply-To: <4741.984103209@sss.pgh.pa.us>; from tgl@sss.pgh.pa.us on Thu, Mar 08, 2001 at 09:00:09PM -0500 +From: ncm@zembu.com (Nathan Myers) +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +On Thu, Mar 08, 2001 at 09:00:09PM -0500, Tom Lane wrote: +> ncm@zembu.com (Nathan Myers) writes: +> > 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 +ncm@zembu.com + +---------------------------(end of broadcast)--------------------------- +TIP 5: Have you checked our extensive FAQ? + +http://www.postgresql.org/users-lounge/docs/faq.html + +From pgsql-hackers-owner+M5638@postgresql.org Fri Mar 9 00:41:08 2001 +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) + (envelope-from pgsql-hackers-owner+M5638@postgresql.org) +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) + (envelope-from dyp@perchine.com) +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 +To: pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Internationalized error messages +Date: Fri, 9 Mar 2001 11:34:42 +0600 +X-Mailer: KMail [version 1.2.1] +References: +In-Reply-To: +MIME-Version: 1.0 +Message-Id: <01030911344204.00457@dyp.perchine.com> +Content-Transfer-Encoding: 8bit +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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 + +---------------------------------- +E-Mail: dyp@perchine.com +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 + +From pgsql-hackers-owner+M5640@postgresql.org Fri Mar 9 06:30:04 2001 +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) + (envelope-from pgsql-hackers-owner+M5640@postgresql.org) +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) + (envelope-from zakkr@zf.jcu.cz) +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 +Cc: pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Internationalized error messages +Message-ID: <20010309085320.A7401@ara.zf.jcu.cz> +References: <20010308164222.Y624@store.zembu.com> <4741.984103209@sss.pgh.pa.us> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +User-Agent: Mutt/1.0.1i +In-Reply-To: <4741.984103209@sss.pgh.pa.us>; from tgl@sss.pgh.pa.us on Thu, Mar 08, 2001 at 09:00:09PM -0500 +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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 + +From pgsql-hackers-owner+M5641@postgresql.org Fri Mar 9 06:43:48 2001 +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) + (envelope-from pgsql-hackers-owner+M5641@postgresql.org) +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) + (envelope-from t-ishii@sra.co.jp) +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 +To: zakkr@zf.jcu.cz +Cc: tgl@sss.pgh.pa.us, pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Internationalized error messages +In-Reply-To: <20010309085320.A7401@ara.zf.jcu.cz> +References: <20010308164222.Y624@store.zembu.com> + <4741.984103209@sss.pgh.pa.us> + <20010309085320.A7401@ara.zf.jcu.cz> +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 +Message-Id: <20010309204226O.t-ishii@sra.co.jp> +Date: Fri, 09 Mar 2001 20:42:26 +0900 +From: Tatsuo Ishii +X-Dispatcher: imput version 20000228(IM140) +Lines: 17 +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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)--------------------------- +TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org + +From pgsql-hackers-owner+M5645@postgresql.org Fri Mar 9 10:37:12 2001 +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) + (envelope-from pgsql-hackers-owner+M5645@postgresql.org) +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) + (envelope-from peter_e@gmx.net) +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) +From: Peter Eisentraut +To: +Subject: Re: [HACKERS] Internationalized error messages +In-Reply-To: <20010308164222.Y624@store.zembu.com> +Message-ID: +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII +X-Sender: 520083510237-0001@t-dialin.net +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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. + +-- +Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ + + +---------------------------(end of broadcast)--------------------------- +TIP 3: if posting/reading through Usenet, please send an appropriate +subscribe-nomail command to majordomo@postgresql.org so that your +message can get through to the mailing list cleanly + +From pgsql-hackers-owner+M5646@postgresql.org Fri Mar 9 10:49:11 2001 +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) + (envelope-from pgsql-hackers-owner+M5646@postgresql.org) +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) + (envelope-from peter_e@gmx.net) +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) +From: Peter Eisentraut +To: Tom Lane +cc: +Subject: Re: [HACKERS] Internationalized error messages +In-Reply-To: <4741.984103209@sss.pgh.pa.us> +Message-ID: +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII +X-Sender: 520083510237-0001@t-dialin.net +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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? + +-- +Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ + + +---------------------------(end of broadcast)--------------------------- +TIP 5: Have you checked our extensive FAQ? + +http://www.postgresql.org/users-lounge/docs/faq.html + +From pgsql-hackers-owner+M5647@postgresql.org Fri Mar 9 11:01:42 2001 +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) + (envelope-from pgsql-hackers-owner+M5647@postgresql.org) +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) + (envelope-from tgl@sss.pgh.pa.us) +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) +To: Peter Eisentraut +cc: pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Internationalized error messages +In-reply-to: +References: +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 +Message-ID: <6895.984153653@sss.pgh.pa.us> +From: Tom Lane +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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 +subscribe-nomail command to majordomo@postgresql.org so that your +message can get through to the mailing list cleanly + +From pgsql-hackers-owner+M5649@postgresql.org Fri Mar 9 11:48:03 2001 +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) + (envelope-from pgsql-hackers-owner+M5649@postgresql.org) +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) + (envelope-from peter_e@gmx.net) +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) +From: Peter Eisentraut +To: Tom Lane +cc: +Subject: Re: [HACKERS] Internationalized error messages +In-Reply-To: <6895.984153653@sss.pgh.pa.us> +Message-ID: +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII +X-Sender: 520083510237-0001@t-dialin.net +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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. + +-- +Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ + + +---------------------------(end of broadcast)--------------------------- +TIP 4: Don't 'kill -9' the postmaster + +From pgsql-hackers-owner+M5650@postgresql.org Fri Mar 9 11:58:51 2001 +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) + (envelope-from pgsql-hackers-owner+M5650@postgresql.org) +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) + (envelope-from peter_e@gmx.net) +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) +From: Peter Eisentraut +To: Karel Zak +cc: Tom Lane , +Subject: Re: [HACKERS] Internationalized error messages +In-Reply-To: <20010309085320.A7401@ara.zf.jcu.cz> +Message-ID: +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII +X-Sender: 520083510237-0001@t-dialin.net +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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"); + +-- +Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ + + +---------------------------(end of broadcast)--------------------------- +TIP 5: Have you checked our extensive FAQ? + +http://www.postgresql.org/users-lounge/docs/faq.html + +From pgsql-hackers-owner+M5651@postgresql.org Fri Mar 9 12:08:40 2001 +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) + (envelope-from pgsql-hackers-owner+M5651@postgresql.org) +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) + (envelope-from tgl@sss.pgh.pa.us) +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) +To: Peter Eisentraut +cc: pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Internationalized error messages +In-reply-to: +References: +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 +Message-ID: <7100.984157522@sss.pgh.pa.us> +From: Tom Lane +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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 + (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) + +From pgsql-hackers-owner+M5665@postgresql.org Fri Mar 9 14:43:45 2001 +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) + (envelope-from pgsql-hackers-owner+M5665@postgresql.org) +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) + (envelope-from andrew@zembu.com) +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 +To: pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Internationalized error messages +Message-ID: <20010309114320.C12977@zembu.com> +Mail-Followup-To: pgsql-hackers@postgresql.org +References: <7100.984157522@sss.pgh.pa.us> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <7100.984157522@sss.pgh.pa.us>; from tgl@sss.pgh.pa.us on Fri, Mar 09, 2001 at 12:05:22PM -0500 +From: Andrew Evans +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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 + +From pgsql-hackers-owner+M5666@postgresql.org Fri Mar 9 14:58:32 2001 +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) + (envelope-from pgsql-hackers-owner+M5666@postgresql.org) +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) + (envelope-from ncm@zembu.com) +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 +To: pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Internationalized error messages +Message-ID: <20010309114920.D624@store.zembu.com> +Reply-To: pgsql-hackers@postgresql.org +References: <7100.984157522@sss.pgh.pa.us> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +User-Agent: Mutt/1.2.5i +In-Reply-To: <7100.984157522@sss.pgh.pa.us>; from tgl@sss.pgh.pa.us on Fri, Mar 09, 2001 at 12:05:22PM -0500 +From: ncm@zembu.com (Nathan Myers) +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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 + +From pgsql-hackers-owner+M5674@postgresql.org Fri Mar 9 15:36:01 2001 +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) + (envelope-from pgsql-hackers-owner+M5674@postgresql.org) +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) + (envelope-from peter_e@gmx.net) +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) +From: Peter Eisentraut +To: Tom Lane +cc: +Subject: Re: [HACKERS] Internationalized error messages +In-Reply-To: <7100.984157522@sss.pgh.pa.us> +Message-ID: +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII +X-Sender: 520083510237-0001@t-dialin.net +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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. :-) + +-- +Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ + + +---------------------------(end of broadcast)--------------------------- +TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org + +From pgsql-hackers-owner+M5675@postgresql.org Fri Mar 9 15:49:07 2001 +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) + (envelope-from pgsql-hackers-owner+M5675@postgresql.org) +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) + (envelope-from tgl@sss.pgh.pa.us) +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) +To: Peter Eisentraut +cc: pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Internationalized error messages +In-reply-to: +References: +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 +Message-ID: <8660.984170913@sss.pgh.pa.us> +From: Tom Lane +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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)--------------------------- +TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org + +From pgsql-hackers-owner+M5801@postgresql.org Tue Mar 13 08:13:36 2001 +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) + (envelope-from pgsql-hackers-owner+M5801@postgresql.org) +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) + (envelope-from pgsql-hackers-owner@postgresql.org) +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) + (envelope-from giles@nemeton.com.au) +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 +To: pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Internationalized error messages +In-Reply-To: Message from Tom Lane + of "Fri, 09 Mar 2001 12:05:22 CDT." <7100.984157522@sss.pgh.pa.us> +Date: Sun, 11 Mar 2001 09:02:16 +1100 +Message-ID: <5428.984261736@nemeton.com.au> +From: Giles Lean +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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)--------------------------- +TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org + +From pgsql-hackers-owner+M5809@postgresql.org Tue Mar 13 10:01:04 2001 +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) + (envelope-from pgsql-hackers-owner+M5809@postgresql.org) +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) + (envelope-from pgsql-hackers-owner@postgresql.org) +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) + (envelope-from prlw1@newn.cam.ac.uk) +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 +From: Patrick Welche +To: Tom Lane +Cc: Peter Eisentraut , pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Internationalized error messages +Message-ID: <20010311181102.B8454@quartz.newn.cam.ac.uk> +Reply-To: prlw1@cam.ac.uk +References: <8660.984170913@sss.pgh.pa.us> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +User-Agent: Mutt/1.2i +In-Reply-To: <8660.984170913@sss.pgh.pa.us>; from tgl@sss.pgh.pa.us on Fri, Mar 09, 2001 at 03:48:33PM -0500 +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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 + (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) + +From pgsql-hackers-owner+M5729@postgresql.org Mon Mar 12 08:38:58 2001 +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) + (envelope-from pgsql-hackers-owner+M5729@postgresql.org) +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) + (envelope-from zakkr@zf.jcu.cz) +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 +To: Peter Eisentraut +Cc: Karel Zak , Tom Lane , + pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Internationalized error messages +Message-ID: <20010312103232.A2268@ara.zf.jcu.cz> +References: <20010309085320.A7401@ara.zf.jcu.cz> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +User-Agent: Mutt/1.0.1i +In-Reply-To: ; from peter_e@gmx.net on Fri, Mar 09, 2001 at 05:57:13PM +0100 +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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 + +From pgsql-hackers-owner+M5734@postgresql.org Mon Mar 12 11:30:24 2001 +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) + (envelope-from pgsql-hackers-owner+M5734@postgresql.org) +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) + (envelope-from peter@retep.org.uk) +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) + (envelope-from peter@retep.org.uk) +Message-Id: <5.0.2.1.0.20010312143839.0214cc90@mail.retep.org.uk> +X-Sender: peter@mail.retep.org.uk +X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 +Date: Mon, 12 Mar 2001 15:09:53 +0000 +To: Peter Eisentraut , + PostgreSQL Development +From: Peter Mount +Subject: Re: [HACKERS] Internationalized error messages +In-Reply-To: +Mime-Version: 1.0 +Content-Type: text/plain; charset="us-ascii"; format=flowed +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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 + +From pgsql-hackers-owner+M5736@postgresql.org Mon Mar 12 14:12:38 2001 +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) + (envelope-from pgsql-hackers-owner+M5736@postgresql.org) +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) + (envelope-from peter_e@gmx.net) +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) +From: Peter Eisentraut +To: Karel Zak +cc: Tom Lane , +Subject: Re: [HACKERS] Internationalized error messages +In-Reply-To: <20010312103232.A2268@ara.zf.jcu.cz> +Message-ID: +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII +X-Sender: 520083510237-0001@t-dialin.net +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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. + +-- +Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ + + +---------------------------(end of broadcast)--------------------------- +TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org + +From pgsql-hackers-owner+M5791@postgresql.org Tue Mar 13 02:41:02 2001 +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) + (envelope-from pgsql-hackers-owner+M5791@postgresql.org) +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) + (envelope-from zakkr@zf.jcu.cz) +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 +To: Peter Eisentraut +Cc: Karel Zak , Tom Lane , + pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Internationalized error messages +Message-ID: <20010313083058.C24468@ara.zf.jcu.cz> +References: <20010312103232.A2268@ara.zf.jcu.cz> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +User-Agent: Mutt/1.0.1i +In-Reply-To: ; from peter_e@gmx.net on Mon, Mar 12, 2001 at 08:15:02PM +0100 +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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 + +From pgsql-hackers-owner+M6177@postgresql.org Mon Mar 19 17:58:41 2001 +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) + (envelope-from pgsql-hackers-owner+M6177@postgresql.org) +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) + (envelope-from peter_e@gmx.net) +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) +From: Peter Eisentraut +To: PostgreSQL Development +Subject: [HACKERS] More on elog and error codes +Message-ID: +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII +X-Sender: 520083510237-0001@t-dialin.net +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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? + +-- +Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ + + +---------------------------(end of broadcast)--------------------------- +TIP 6: Have you searched our list archives? + +http://www.postgresql.org/search.mpl + +From pgsql-hackers-owner+M6182@postgresql.org Mon Mar 19 19:19:38 2001 +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) + (envelope-from pgsql-hackers-owner+M6182@postgresql.org) +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) + (envelope-from pjw@rhyme.com.au) +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 +Message-Id: <3.0.5.32.20010320104855.0339d300@mail.rhyme.com.au> +X-Sender: pjw@mail.rhyme.com.au +X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) +Date: Tue, 20 Mar 2001 10:48:55 +1100 +To: Peter Eisentraut , + PostgreSQL Development +From: Philip Warner +Subject: Re: [HACKERS] More on elog and error codes +In-Reply-To: +Mime-Version: 1.0 +Content-Type: text/plain; charset="us-ascii" +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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)--------------------------- +TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org + +From pgsql-hackers-owner+M6184@postgresql.org Mon Mar 19 19:36:40 2001 +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) + (envelope-from pgsql-hackers-owner+M6184@postgresql.org) +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) + (envelope-from tgl@sss.pgh.pa.us) +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) +To: Philip Warner +cc: Peter Eisentraut , + PostgreSQL Development +Subject: Re: [HACKERS] More on elog and error codes +In-reply-to: <3.0.5.32.20010320104855.0339d300@mail.rhyme.com.au> +References: <3.0.5.32.20010320104855.0339d300@mail.rhyme.com.au> +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 +Message-ID: <8326.985048522@sss.pgh.pa.us> +From: Tom Lane +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +Philip Warner writes: +> 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 + +From pgsql-hackers-owner+M6205@postgresql.org Tue Mar 20 11:30:33 2001 +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) + (envelope-from pgsql-hackers-owner+M6205@postgresql.org) +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) + (envelope-from peter_e@gmx.net) +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) +From: Peter Eisentraut +To: Philip Warner +cc: PostgreSQL Development +Subject: Re: [HACKERS] More on elog and error codes +In-Reply-To: <3.0.5.32.20010320104855.0339d300@mail.rhyme.com.au> +Message-ID: +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII +X-Sender: 520083510237-0001@t-dialin.net +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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. + +-- +Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ + + +---------------------------(end of broadcast)--------------------------- +TIP 3: if posting/reading through Usenet, please send an appropriate +subscribe-nomail command to majordomo@postgresql.org so that your +message can get through to the mailing list cleanly + +From pgsql-hackers-owner+M6236@postgresql.org Tue Mar 20 16:59:30 2001 +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) + (envelope-from pgsql-hackers-owner+M6236@postgresql.org) +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) + (envelope-from csawtell@xtra.co.nz) +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 +To: Peter Eisentraut , + PostgreSQL Development +Subject: Re: [HACKERS] More on elog and error codes +Date: Wed, 21 Mar 2001 09:41:44 +1200 +X-Mailer: KMail [version 1.2] +References: +In-Reply-To: +MIME-Version: 1.0 +Message-Id: <01032109414401.09393@berty> +Content-Transfer-Encoding: 8bit +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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)--------------------------- +TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org + +From pgsql-hackers-owner+M6239@postgresql.org Tue Mar 20 17:12:06 2001 +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) + (envelope-from pgsql-hackers-owner+M6239@postgresql.org) +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) + (envelope-from reedstrm@rice.edu) +Received: by rice.edu + via sendmail from stdin + id (Debian Smail3.2.0.102) + for pgsql-hackers@postgresql.org; Tue, 20 Mar 2001 16:10:57 -0600 (CST) +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 +Message-ID: <20010320161057.C1703@rice.edu> +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 csawtell@xtra.co.nz on Wed, Mar 21, 2001 at 09:41:44AM +1200 +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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 +subscribe-nomail command to majordomo@postgresql.org so that your +message can get through to the mailing list cleanly + +From pgsql-hackers-owner+M6244@postgresql.org Tue Mar 20 17:46:15 2001 +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) + (envelope-from pgsql-hackers-owner+M6244@postgresql.org) +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) + (envelope-from pjw@rhyme.com.au) +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 +Message-Id: <3.0.5.32.20010321094352.0287ad00@mail.rhyme.com.au> +X-Sender: pjw@mail.rhyme.com.au +X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) +Date: Wed, 21 Mar 2001 09:43:52 +1100 +To: Peter Eisentraut +From: Philip Warner +Subject: Re: [HACKERS] More on elog and error codes +Cc: PostgreSQL Development +In-Reply-To: +References: <3.0.5.32.20010320104855.0339d300@mail.rhyme.com.au> +Mime-Version: 1.0 +Content-Type: text/plain; charset="us-ascii" +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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 + +From pgsql-hackers-owner+M6246@postgresql.org Tue Mar 20 17:48:13 2001 +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) + (envelope-from pgsql-hackers-owner+M6246@postgresql.org) +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) + (envelope-from pjw@rhyme.com.au) +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 +Message-Id: <3.0.5.32.20010321094655.02852720@mail.rhyme.com.au> +X-Sender: pjw@mail.rhyme.com.au +X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) +Date: Wed, 21 Mar 2001 09:46:55 +1100 +To: Christopher Sawtell , + Peter Eisentraut , + PostgreSQL Development +From: Philip Warner +Subject: Re: [HACKERS] More on elog and error codes +In-Reply-To: <01032109414401.09393@berty> +References: + +Mime-Version: 1.0 +Content-Type: text/plain; charset="us-ascii" +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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 + (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) + +From pgsql-hackers-owner+M6288@postgresql.org Tue Mar 20 21:47:12 2001 +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) + (envelope-from pgsql-hackers-owner+M6288@postgresql.org) +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) + (envelope-from pjw@rhyme.com.au) +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 +Message-Id: <3.0.5.32.20010321134325.028a4e90@mail.rhyme.com.au> +X-Sender: pjw@mail.rhyme.com.au +X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) +Date: Wed, 21 Mar 2001 13:43:25 +1100 +To: Peter Eisentraut +From: Philip Warner +Subject: Re: [HACKERS] More on elog and error codes +Cc: PostgreSQL Development +In-Reply-To: <3.0.5.32.20010321094352.0287ad00@mail.rhyme.com.au> +References: + <3.0.5.32.20010320104855.0339d300@mail.rhyme.com.au> +Mime-Version: 1.0 +Content-Type: text/plain; charset="us-ascii" +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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 + (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) + +From pgsql-hackers-owner+M6357@postgresql.org Wed Mar 21 15:55:00 2001 +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) + (envelope-from pgsql-hackers-owner+M6357@postgresql.org) +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) + (envelope-from peter_e@gmx.net) +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) +From: Peter Eisentraut +To: Philip Warner +cc: PostgreSQL Development +Subject: Re: [HACKERS] More on elog and error codes +In-Reply-To: <3.0.5.32.20010321094352.0287ad00@mail.rhyme.com.au> +Message-ID: +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII +X-Sender: 520083510237-0001@t-dialin.net +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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. + +-- +Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ + + +---------------------------(end of broadcast)--------------------------- +TIP 3: if posting/reading through Usenet, please send an appropriate +subscribe-nomail command to majordomo@postgresql.org so that your +message can get through to the mailing list cleanly + +From pgsql-hackers-owner+M6370@postgresql.org Wed Mar 21 20:32:02 2001 +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) + (envelope-from pgsql-hackers-owner+M6370@postgresql.org) +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) + (envelope-from pjw@rhyme.com.au) +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 +Message-Id: <3.0.5.32.20010322123019.02a9e760@mail.rhyme.com.au> +X-Sender: pjw@mail.rhyme.com.au +X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) +Date: Thu, 22 Mar 2001 12:30:19 +1100 +To: Peter Eisentraut +From: Philip Warner +Subject: Re: [HACKERS] More on elog and error codes +Cc: PostgreSQL Development +In-Reply-To: +References: <3.0.5.32.20010321094352.0287ad00@mail.rhyme.com.au> +Mime-Version: 1.0 +Content-Type: text/plain; charset="us-ascii" +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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 + +From pgsql-hackers-owner+M6392@postgresql.org Wed Mar 21 23:27:40 2001 +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) + (envelope-from pgsql-hackers-owner+M6392@postgresql.org) +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) + (envelope-from tgl@sss.pgh.pa.us) +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) +To: Philip Warner +cc: Peter Eisentraut , + PostgreSQL Development +Subject: Re: [HACKERS] More on elog and error codes +In-reply-to: <3.0.5.32.20010322123019.02a9e760@mail.rhyme.com.au> +References: <3.0.5.32.20010321094352.0287ad00@mail.rhyme.com.au> <3.0.5.32.20010322123019.02a9e760@mail.rhyme.com.au> +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 +Message-ID: <7980.985235097@sss.pgh.pa.us> +From: Tom Lane +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +I've pretty much got to agree with Peter on both of these points. + +Philip Warner writes: +> 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 + +From pgsql-hackers-owner+M6397@postgresql.org Wed Mar 21 23:50:40 2001 +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) + (envelope-from pgsql-hackers-owner+M6397@postgresql.org) +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) + (envelope-from pjw@rhyme.com.au) +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 +Message-Id: <3.0.5.32.20010322154752.02983550@mail.rhyme.com.au> +X-Sender: pjw@mail.rhyme.com.au +X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) +Date: Thu, 22 Mar 2001 15:47:52 +1100 +To: Peter Eisentraut +From: Philip Warner +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 +Sender: pgsql-hackers-owner@postgresql.org +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 +subscribe-nomail command to majordomo@postgresql.org so that your +message can get through to the mailing list cleanly + +From pgsql-hackers-owner+M6411@postgresql.org Thu Mar 22 00:21:12 2001 +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) + (envelope-from pgsql-hackers-owner+M6411@postgresql.org) +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) + (envelope-from pjw@rhyme.com.au) +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 +Message-Id: <3.0.5.32.20010322161938.02a87a70@mail.rhyme.com.au> +X-Sender: pjw@mail.rhyme.com.au +X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) +Date: Thu, 22 Mar 2001 16:19:38 +1100 +To: Tom Lane +From: Philip Warner +Subject: Re: [HACKERS] More on elog and error codes +Cc: Peter Eisentraut , + PostgreSQL Development +In-Reply-To: <7980.985235097@sss.pgh.pa.us> +References: <3.0.5.32.20010322123019.02a9e760@mail.rhyme.com.au> + <3.0.5.32.20010321094352.0287ad00@mail.rhyme.com.au> + <3.0.5.32.20010322123019.02a9e760@mail.rhyme.com.au> +Mime-Version: 1.0 +Content-Type: text/plain; charset="us-ascii" +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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. + + +>Philip Warner writes: +>> 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 + +From pgsql-hackers-owner+M6412@postgresql.org Thu Mar 22 00:39:33 2001 +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) + (envelope-from pgsql-hackers-owner+M6412@postgresql.org) +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) + (envelope-from tgl@sss.pgh.pa.us) +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) +To: Philip Warner +cc: Peter Eisentraut , + PostgreSQL Development +Subject: Re: [HACKERS] More on elog and error codes +In-reply-to: <3.0.5.32.20010322161938.02a87a70@mail.rhyme.com.au> +References: <3.0.5.32.20010322123019.02a9e760@mail.rhyme.com.au> <3.0.5.32.20010321094352.0287ad00@mail.rhyme.com.au> <3.0.5.32.20010322123019.02a9e760@mail.rhyme.com.au> <3.0.5.32.20010322161938.02a87a70@mail.rhyme.com.au> +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 +Message-ID: <18631.985239348@sss.pgh.pa.us> +From: Tom Lane +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +Philip Warner writes: +> 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 + +From pgsql-hackers-owner+M6417@postgresql.org Thu Mar 22 01:42:24 2001 +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) + (envelope-from pgsql-hackers-owner+M6417@postgresql.org) +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) + (envelope-from pjw@rhyme.com.au) +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 +Message-Id: <3.0.5.32.20010322174022.00b4fe60@mail.rhyme.com.au> +X-Sender: pjw@mail.rhyme.com.au +X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) +Date: Thu, 22 Mar 2001 17:40:22 +1100 +To: Tom Lane +From: Philip Warner +Subject: Re: [HACKERS] More on elog and error codes +Cc: Peter Eisentraut , + PostgreSQL Development +In-Reply-To: <18631.985239348@sss.pgh.pa.us> +References: <3.0.5.32.20010322161938.02a87a70@mail.rhyme.com.au> + <3.0.5.32.20010322123019.02a9e760@mail.rhyme.com.au> + <3.0.5.32.20010321094352.0287ad00@mail.rhyme.com.au> + <3.0.5.32.20010322123019.02a9e760@mail.rhyme.com.au> + <3.0.5.32.20010322161938.02a87a70@mail.rhyme.com.au> +Mime-Version: 1.0 +Content-Type: text/plain; charset="us-ascii" +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +Status: OR + +At 00:35 22/03/01 -0500, Tom Lane wrote: +>Philip Warner writes: +>> 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 + +From pgsql-hackers-owner+M6178@postgresql.org Mon Mar 19 18:04:16 2001 +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) + (envelope-from pgsql-hackers-owner+M6178@postgresql.org) +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) + (envelope-from peter_e@gmx.net) +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) +From: Peter Eisentraut +To: PostgreSQL Development +Subject: [HACKERS] elog with automatic file, line, and function +Message-ID: +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII +X-Sender: 520083510237-0001@t-dialin.net +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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. + +-- +Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ + + +---------------------------(end of broadcast)--------------------------- +TIP 2: you can get off all lists at once with the unregister command + (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) + +From pgsql-hackers-owner+M6181@postgresql.org Mon Mar 19 18:26:30 2001 +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) + (envelope-from pgsql-hackers-owner+M6181@postgresql.org) +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) + (envelope-from tgl@sss.pgh.pa.us) +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) +To: Peter Eisentraut +cc: PostgreSQL Development +Subject: Re: [HACKERS] elog with automatic file, line, and function +In-reply-to: +References: +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 +Message-ID: <7932.985044210@sss.pgh.pa.us> +From: Tom Lane +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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 +subscribe-nomail command to majordomo@postgresql.org so that your +message can get through to the mailing list cleanly + +From pgsql-hackers-owner+M6183@postgresql.org Mon Mar 19 19:34:34 2001 +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) + (envelope-from pgsql-hackers-owner+M6183@postgresql.org) +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) + (envelope-from ian@airs.com) +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 +Mail-Followup-To: peter_e@gmx.net, + pgsql-hackers@postgresql.org, + tgl@sss.pgh.pa.us +To: Tom Lane +Cc: Peter Eisentraut , + PostgreSQL Development +Subject: Re: [HACKERS] elog with automatic file, line, and function +References: + <7932.985044210@sss.pgh.pa.us> +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 +Sender: pgsql-hackers-owner@postgresql.org +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 + +From pgsql-hackers-owner+M6185@postgresql.org Mon Mar 19 20:00:25 2001 +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) + (envelope-from pgsql-hackers-owner+M6185@postgresql.org) +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) + (envelope-from tgl@sss.pgh.pa.us) +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 +cc: Peter Eisentraut , + PostgreSQL Development +Subject: Re: [HACKERS] elog with automatic file, line, and function +In-reply-to: +References: <7932.985044210@sss.pgh.pa.us> +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 +Message-ID: <8353.985048716@sss.pgh.pa.us> +From: Tom Lane +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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 +subscribe-nomail command to majordomo@postgresql.org so that your +message can get through to the mailing list cleanly + +From pgsql-hackers-owner+M6188@postgresql.org Mon Mar 19 20:29:45 2001 +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) + (envelope-from pgsql-hackers-owner+M6188@postgresql.org) +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) + (envelope-from ler@lerctr.org) +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 , + PostgreSQL Development +Subject: Re: [HACKERS] elog with automatic file, line, and function +Message-ID: <20010319192547.A29294@lerami.lerctr.org> +References: <7932.985044210@sss.pgh.pa.us> <8353.985048716@sss.pgh.pa.us> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +User-Agent: Mutt/1.3.16i +In-Reply-To: <8353.985048716@sss.pgh.pa.us>; from tgl@sss.pgh.pa.us on Mon, Mar 19, 2001 at 07:38:36PM -0500 +X-Mailer: Mutt http://www.mutt.org/ +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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 +> subscribe-nomail command to majordomo@postgresql.org so that your +> message can get through to the mailing list cleanly +-- +Larry Rosenman http://www.lerctr.org/~ler +Phone: +1 972-414-9812 E-Mail: ler@lerctr.org +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 + +From pgsql-hackers-owner+M6189@postgresql.org Mon Mar 19 20:49:49 2001 +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) + (envelope-from pgsql-hackers-owner+M6189@postgresql.org) +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) + (envelope-from nnorwitz@yahoo.com) +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: +Message-ID: <3AB6B5EB.21F2D551@yahoo.com> +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 +To: peter_e@gmx.net, pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] elog with automatic file, line, and function +Content-Type: text/plain; charset=us-ascii +Content-Transfer-Encoding: 7bit +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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 + +From pgsql-hackers-owner+M6355@postgresql.org Wed Mar 21 15:48:41 2001 +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) + (envelope-from pgsql-hackers-owner+M6355@postgresql.org) +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) + (envelope-from peter_e@gmx.net) +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) +From: Peter Eisentraut +To: Tom Lane +cc: PostgreSQL Development +Subject: Re: [HACKERS] elog with automatic file, line, and function +In-Reply-To: <7932.985044210@sss.pgh.pa.us> +Message-ID: +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII +X-Sender: 520083510237-0001@t-dialin.net +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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? + +-- +Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ + + +---------------------------(end of broadcast)--------------------------- +TIP 6: Have you searched our list archives? + +http://www.postgresql.org/search.mpl + +From pgsql-hackers-owner+M6376@postgresql.org Wed Mar 21 21:55:11 2001 +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) + (envelope-from pgsql-hackers-owner+M6376@postgresql.org) +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) + (envelope-from tgl@sss.pgh.pa.us) +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) +To: Peter Eisentraut +cc: PostgreSQL Development +Subject: Re: [HACKERS] elog with automatic file, line, and function +In-reply-to: +References: +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 +Message-ID: <2815.985229663@sss.pgh.pa.us> +From: Tom Lane +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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 +subscribe-nomail command to majordomo@postgresql.org so that your +message can get through to the mailing list cleanly + +From pgsql-hackers-owner+M6210@postgresql.org Tue Mar 20 11:55:39 2001 +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) + (envelope-from pgsql-hackers-owner+M6210@postgresql.org) +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) + (envelope-from ZeugswetterA@wien.spardat.at) +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 +Sender: pgsql-hackers-owner@postgresql.org +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 + (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) + +From pgsql-hackers-owner+M6212@postgresql.org Tue Mar 20 12:35:33 2001 +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) + (envelope-from pgsql-hackers-owner+M6212@postgresql.org) +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) + (envelope-from tgl@sss.pgh.pa.us) +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 , + PostgreSQL Development +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 +Message-ID: <11498.985109378@sss.pgh.pa.us> +From: Tom Lane +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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 + (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) + +From pgsql-hackers-owner+M6211@postgresql.org Tue Mar 20 11:59:14 2001 +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) + (envelope-from pgsql-hackers-owner+M6211@postgresql.org) +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) + (envelope-from ler@lerctr.org) +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) + (envelope-from ler@lerctr.org) +From: Larry Rosenman +Date: Tue, 20 Mar 2001 16:57:38 GMT +Message-ID: <20010320.16573800@ler-freebie.iadfw.net> +Subject: Re: AW: [HACKERS] Re: More on elog and error codes +To: Peter Eisentraut +CC: Zeugswetter Andreas SB , + =?US-ASCII?Q?=27lockhart=40fourpalms=2Eorg=27?= , + =?US-ASCII?Q?PostgreSQL?= Development +In-Reply-To: +References: +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 +Sender: pgsql-hackers-owner@postgresql.org +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. + +> -- +> Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/ + + +> ---------------------------(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 + (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) + +From pgsql-hackers-owner+M6238@postgresql.org Tue Mar 20 17:10:47 2001 +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) + (envelope-from pgsql-hackers-owner+M6238@postgresql.org) +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) + (envelope-from otto.hirr@olabinc.com) +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) + (envelope-from otto.hirr@olabinc.com) +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 +Message-ID: <000001c0b187$8d761000$7bf7663f@xcdt.olabinc.com> +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 +Sender: pgsql-hackers-owner@postgresql.org +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. +otto.hirr@olabinc.com +503 / 617-6595 + + +---------------------------(end of broadcast)--------------------------- +TIP 2: you can get off all lists at once with the unregister command + (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) + +From pgsql-hackers-owner+M6294@postgresql.org Tue Mar 20 22:29:16 2001 +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) + (envelope-from pgsql-hackers-owner+M6294@postgresql.org) +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) + (envelope-from lockhart@alumni.caltech.edu) +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) +Message-ID: <3AB81FD8.5260E97A@alumni.caltech.edu> +Date: Wed, 21 Mar 2001 03:28:24 +0000 +From: Thomas Lockhart +Reply-To: lockhart@fourpalms.org +Organization: Yes +X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17-21mdksmp i686) +X-Accept-Language: en +MIME-Version: 1.0 +To: Philip Warner +Cc: Peter Eisentraut , + PostgreSQL Development +Subject: [HACKERS] Re: More on elog and error codes +References: <3.0.5.32.20010320104855.0339d300@mail.rhyme.com.au> <3.0.5.32.20010321094352.0287ad00@mail.rhyme.com.au> +Content-Type: text/plain; charset=us-ascii +Content-Transfer-Encoding: 7bit +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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)--------------------------- +TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org + +From pgsql-hackers-owner+M6295@postgresql.org Tue Mar 20 22:40:59 2001 +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) + (envelope-from pgsql-hackers-owner+M6295@postgresql.org) +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) + (envelope-from pjw@rhyme.com.au) +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 +Message-Id: <3.0.5.32.20010321143821.00af1e70@mail.rhyme.com.au> +X-Sender: pjw@mail.rhyme.com.au +X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) +Date: Wed, 21 Mar 2001 14:38:21 +1100 +To: lockhart@fourpalms.org +From: Philip Warner +Subject: [HACKERS] Re: More on elog and error codes +Cc: Peter Eisentraut , + PostgreSQL Development +In-Reply-To: <3AB81FD8.5260E97A@alumni.caltech.edu> +References: <3.0.5.32.20010320104855.0339d300@mail.rhyme.com.au> + <3.0.5.32.20010321094352.0287ad00@mail.rhyme.com.au> +Mime-Version: 1.0 +Content-Type: text/plain; charset="us-ascii" +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +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)--------------------------- +TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org +