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