diff --git a/doc/FAQ b/doc/FAQ index d1b9900e062..f503f576433 100644 --- a/doc/FAQ +++ b/doc/FAQ @@ -1,7 +1,7 @@ Frequently Asked Questions (FAQ) for PostgreSQL - Last updated: Mon Nov 12 02:38:47 EST 2001 + Last updated: Tue Nov 27 14:16:49 EST 2001 Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us) @@ -28,6 +28,7 @@ 1.12) How do I join the development team? 1.13) How do I submit a bug report? 1.14) How does PostgreSQL compare to other DBMS's? + 1.14) How can I financially assist PostgreSQL? User Client Questions @@ -358,6 +359,28 @@ We are free for all use, both commercial and non-commercial. You can add our code to your product with no limitations, except those outlined in our BSD-style license stated above. + + 1.13) How can I financially assist PostgreSQL? + + PostgreSQL has had a first-class infrastructure since we started five + years ago. This is all thanks to Marc Fournier, who has created and + managed this infrastructure over the years. + + Quality infrastructure is very important to an open-source project. It + prevents disruptions that can greatly delay forward movement of the + project. + + Of course, this infrastructure is not cheap. There are a variety of + monthly and one-time expenses that are required to keep it going. If + you or your company has money it can donate to help fund this effort, + please go to the following URL and make a donation: + + http://www.pgsql.com/pg_goodies + + Although the web page mentions PostgreSQL, Inc, the "contributions" + item is solely to support the PostgreSQL project and does not fund any + specific company. If you prefer, you can also send a check to the + contact address. _________________________________________________________________ User Client Questions diff --git a/doc/TODO.detail/atttypmod b/doc/TODO.detail/atttypmod deleted file mode 100644 index 1527139a3f3..00000000000 --- a/doc/TODO.detail/atttypmod +++ /dev/null @@ -1,56 +0,0 @@ -From tgl@sss.pgh.pa.us Sun May 23 12:32:34 1999 -Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) - by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id MAA23977 - for ; Sun, 23 May 1999 12:32:33 -0400 (EDT) -Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) - by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id MAA19926; - Sun, 23 May 1999 12:32:01 -0400 (EDT) -To: Bruce Momjian -cc: PostgreSQL-development -Subject: Re: [HACKERS] DEFAULT fixed -In-reply-to: Your message of Sat, 22 May 1999 21:12:19 -0400 (EDT) - <199905230112.VAA13489@candle.pha.pa.us> -Date: Sun, 23 May 1999 12:32:01 -0400 -Message-ID: <19923.927477121@sss.pgh.pa.us> -From: Tom Lane -Status: ROr - -Bruce Momjian writes: ->> It might be best to just bite the bullet and make the parser carry ->> around both the type's OID and typmod at all times. - -> I will try to add it, but I must not that there are some cases where I -> don't have access to the atttypmod of the result, so it may not be -> possible to do it in every case. Perhaps I should just leave this for -> post 6.5, because we don't have any other bug reports on it. - -After further thought, I think this may be a more difficult and subtle -issue than we've realized. In the current state of the system, there -are many places where you have a value that you can only know the type -OID for, not atttypmod --- specifically, any intermediate expression -result. Barring reworking the entire function-call mechanism to pass -atttypmod around, that's not going to be possible to change. - -The only context where you really know atttypmod is where you have -just fetched a value out of a table column or are about to store a -value into a table column. When storing, you need to be prepared to -coerce the given value to the right type if *either* type OID or -atttypmod is different --- but, in general, you don't know atttypmod -for the given value. (In the cases I know of, you can deduce it by -examining the value itself, but this requires type-specific knowledge.) - -So on the whole I think this is something that has to be dealt with -at the point of storing data into a tuple. Maybe we need a new -fundamental operation for types that pay attention to atttypmod: -"make this value match the typmod of the target column, which is -thus-and-so". Trying to attack the problem from the source side by -propagating typmod all around the parser is probably doomed to failure, -because there will be many contexts where there's no way to know it. - -Since you have a fix for the only symptom reported to date, I'm -inclined to agree that we should leave well enough alone for now; -there are other, bigger, problems that we need to address for 6.5. -But I think we'll have to come back to this issue later. - - regards, tom lane - diff --git a/doc/TODO.detail/elog b/doc/TODO.detail/elog deleted file mode 100644 index 7a35a488870..00000000000 --- a/doc/TODO.detail/elog +++ /dev/null @@ -1,3961 +0,0 @@ -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 - diff --git a/doc/TODO.detail/tcl_arrays b/doc/TODO.detail/tcl_arrays deleted file mode 100644 index 117dc6eb00a..00000000000 --- a/doc/TODO.detail/tcl_arrays +++ /dev/null @@ -1,240 +0,0 @@ -From owner-pgsql-patches@hub.org Wed Oct 14 17:31:26 1998 -Received: from renoir.op.net (root@renoir.op.net [209.152.193.4]) - by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id RAA01594 - for ; Wed, 14 Oct 1998 17:31:24 -0400 (EDT) -Received: from hub.org (majordom@hub.org [209.47.148.200]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id RAA01745 for ; Wed, 14 Oct 1998 17:12:28 -0400 (EDT) -Received: from localhost (majordom@localhost) - by hub.org (8.8.8/8.8.8) with SMTP id RAA06607; - Wed, 14 Oct 1998 17:10:43 -0400 (EDT) - (envelope-from owner-pgsql-patches@hub.org) -Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Wed, 14 Oct 1998 17:10:27 +0000 (EDT) -Received: (from majordom@localhost) - by hub.org (8.8.8/8.8.8) id RAA06562 - for pgsql-patches-outgoing; Wed, 14 Oct 1998 17:10:26 -0400 (EDT) - (envelope-from owner-pgsql-patches@postgreSQL.org) -X-Authentication-Warning: hub.org: majordom set sender to owner-pgsql-patches@postgreSQL.org using -f -Received: from mambo.cs.unitn.it (mambo.cs.unitn.it [193.205.199.204]) - by hub.org (8.8.8/8.8.8) with SMTP id RAA06494 - for ; Wed, 14 Oct 1998 17:10:01 -0400 (EDT) - (envelope-from dz@cs.unitn.it) -Received: from nikita.wizard.net (ts-slip31.gelso.unitn.it [193.205.200.31]) by mambo.cs.unitn.it (8.6.12/8.6.12) with ESMTP id XAA20316 for ; Wed, 14 Oct 1998 23:09:52 +0200 -Received: (from dz@localhost) by nikita.wizard.net (8.8.5/8.6.9) id WAA00489 for pgsql-patches@postgreSQL.org; Wed, 14 Oct 1998 22:56:58 +0200 -From: Massimo Dal Zotto -Message-Id: <199810142056.WAA00489@nikita.wizard.net> -Subject: [PATCHES] TCL_ARRAYS -To: pgsql-patches@postgreSQL.org (Pgsql Patches) -Date: Wed, 14 Oct 1998 22:56:58 +0200 (MET DST) -X-Mailer: ELM [version 2.4 PL24 ME4] -MIME-Version: 1.0 -Content-Type: text/plain; charset=iso-8859-1 -Content-Transfer-Encoding: 8bit -Sender: owner-pgsql-patches@postgreSQL.org -Precedence: bulk -Status: RO - -Hi, - -I have written this patch which fixes some problems with TCL_ARRAYS. -The new array code uses a temporary buffer and is disabled by default -because it depends on contrib/string-io which most of you don't use. -This raises once again the problem of backslashes/escapes and various -ambiguities in pgsql output. I hope this will be solved in 6.5. - -*** src/interfaces/libpgtcl/pgtclCmds.c.orig Mon Sep 21 09:00:19 1998 ---- src/interfaces/libpgtcl/pgtclCmds.c Wed Oct 14 15:32:21 1998 -*************** -*** 602,616 **** - { - for (i = 0; i < PQnfields(result); i++) - { - sprintf(nameBuffer, "%d,%.200s", tupno, PQfname(result, i)); - if (Tcl_SetVar2(interp, arrVar, nameBuffer, -! #ifdef TCL_ARRAYS -! tcl_value(PQgetvalue(result, tupno, i)), - #else - PQgetvalue(result, tupno, i), -- #endif - TCL_LEAVE_ERR_MSG) == NULL) - return TCL_ERROR; - } - } - Tcl_AppendResult(interp, arrVar, 0); ---- 602,624 ---- - { - for (i = 0; i < PQnfields(result); i++) - { -+ #ifdef TCL_ARRAYS -+ char *buff = strdup(PQgetvalue(result, tupno, i)); - sprintf(nameBuffer, "%d,%.200s", tupno, PQfname(result, i)); - if (Tcl_SetVar2(interp, arrVar, nameBuffer, -! tcl_value(buff), -! TCL_LEAVE_ERR_MSG) == NULL) { -! free(buff); -! return TCL_ERROR; -! } -! free(buff); - #else -+ sprintf(nameBuffer, "%d,%.200s", tupno, PQfname(result, i)); -+ if (Tcl_SetVar2(interp, arrVar, nameBuffer, - PQgetvalue(result, tupno, i), - TCL_LEAVE_ERR_MSG) == NULL) - return TCL_ERROR; -+ #endif - } - } - Tcl_AppendResult(interp, arrVar, 0); -*************** -*** 636,643 **** - */ - for (tupno = 0; tupno < PQntuples(result); tupno++) - { - const char *field0 = PQgetvalue(result, tupno, 0); -! char * workspace = malloc(strlen(field0) + strlen(appendstr) + 210); - - for (i = 1; i < PQnfields(result); i++) - { ---- 644,674 ---- - */ - for (tupno = 0; tupno < PQntuples(result); tupno++) - { -+ #ifdef TCL_ARRAYS -+ char *buff = strdup(PQgetvalue(result, tupno, 0)); -+ const char *field0 = tcl_value(buff); -+ char *workspace = malloc(strlen(field0) + 210 + strlen(appendstr)); -+ -+ for (i = 1; i < PQnfields(result); i++) -+ { -+ free(buff); -+ buff = strdup(PQgetvalue(result, tupno, i)); -+ sprintf(workspace, "%s,%.200s%s", field0, PQfname(result,i), -+ appendstr); -+ if (Tcl_SetVar2(interp, arrVar, workspace, -+ tcl_value(buff), -+ TCL_LEAVE_ERR_MSG) == NULL) -+ { -+ free(buff); -+ free(workspace); -+ return TCL_ERROR; -+ } -+ } -+ free(buff); -+ free(workspace); -+ #else - const char *field0 = PQgetvalue(result, tupno, 0); -! char *workspace = malloc(strlen(field0) + 210 + strlen(appendstr)); - - for (i = 1; i < PQnfields(result); i++) - { -*************** -*** 652,657 **** ---- 683,689 ---- - } - } - free(workspace); -+ #endif - } - Tcl_AppendResult(interp, arrVar, 0); - return TCL_OK; -*************** -*** 669,676 **** ---- 701,716 ---- - Tcl_AppendResult(interp, "argument to getTuple cannot exceed number of tuples - 1", 0); - return TCL_ERROR; - } -+ #ifdef TCL_ARRAYS -+ for (i = 0; i < PQnfields(result); i++) { -+ char *buff = strdup(PQgetvalue(result, tupno, i)); -+ Tcl_AppendElement(interp, tcl_value(buff)); -+ free(buff); -+ } -+ #else - for (i = 0; i < PQnfields(result); i++) - Tcl_AppendElement(interp, PQgetvalue(result, tupno, i)); -+ #endif - return TCL_OK; - } - else if (strcmp(opt, "-tupleArray") == 0) -*************** -*** 688,697 **** ---- 728,748 ---- - } - for (i = 0; i < PQnfields(result); i++) - { -+ #ifdef TCL_ARRAYS -+ char *buff = strdup(PQgetvalue(result, tupno, i)); -+ if (Tcl_SetVar2(interp, argv[4], PQfname(result, i), -+ tcl_value(buff), -+ TCL_LEAVE_ERR_MSG) == NULL) { -+ free(buff); -+ return TCL_ERROR; -+ } -+ free(buff); -+ #else - if (Tcl_SetVar2(interp, argv[4], PQfname(result, i), - PQgetvalue(result, tupno, i), - TCL_LEAVE_ERR_MSG) == NULL) - return TCL_ERROR; -+ #endif - } - return TCL_OK; - } -*************** -*** 1303,1310 **** - sprintf(buffer, "%d", tupno); - Tcl_SetVar2(interp, argv[3], ".tupno", buffer, 0); - - for (column = 0; column < ncols; column++) -! Tcl_SetVar2(interp, argv[3], info[column].cname, PQgetvalue(result, tupno, column), 0); - - Tcl_SetVar2(interp, argv[3], ".command", "update", 0); - ---- 1354,1371 ---- - sprintf(buffer, "%d", tupno); - Tcl_SetVar2(interp, argv[3], ".tupno", buffer, 0); - -+ #ifdef TCL_ARRAYS -+ for (column = 0; column < ncols; column++) { -+ char *buff = strdup(PQgetvalue(result, tupno, column)); -+ Tcl_SetVar2(interp, argv[3], info[column].cname, -+ tcl_value(buff), 0); -+ free(buff); -+ } -+ #else - for (column = 0; column < ncols; column++) -! Tcl_SetVar2(interp, argv[3], info[column].cname, -! PQgetvalue(result, tupno, column), 0); -! #endif - - Tcl_SetVar2(interp, argv[3], ".command", "update", 0); - -*** src/include/config.h.in.orig Wed Aug 26 09:01:16 1998 ---- src/include/config.h.in Wed Oct 14 22:44:00 1998 -*************** -*** 312,318 **** - * of postgres C-like arrays, for example {{"a1" "a2"} {"b1" "b2"}} instead - * of {{"a1","a2"},{"b1","b2"}}. - */ -! #define TCL_ARRAYS - - /* - * The following flag allows limiting the number of rows returned by a query. ---- 312,318 ---- - * of postgres C-like arrays, for example {{"a1" "a2"} {"b1" "b2"}} instead - * of {{"a1","a2"},{"b1","b2"}}. - */ -! /* #define TCL_ARRAYS */ - - /* - * The following flag allows limiting the number of rows returned by a query. - --- -Massimo Dal Zotto - -+----------------------------------------------------------------------+ -| Massimo Dal Zotto email: dz@cs.unitn.it | -| Via Marconi, 141 phone: ++39-461-534251 | -| 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ | -| Italy pgp: finger dz@tango.cs.unitn.it | -+----------------------------------------------------------------------+ - -