mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-24 01:17:19 +02:00
3962 lines
171 KiB
Plaintext
3962 lines
171 KiB
Plaintext
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <pgsql-hackers@postgresql.org>; 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: <Pine.LNX.4.30.0103082319150.1061-100000@peter.localdomain> <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 <tgl@sss.pgh.pa.us>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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: <Pine.LNX.4.30.0103082319150.1061-100000@peter.localdomain> <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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <pgsql-hackers@postgresql.org>; Fri, 9 Mar 2001 11:36:07 +0600
|
|
Content-Type: text/plain;
|
|
charset="koi8-r"
|
|
From: Denis Perchine <dyp@perchine.com>
|
|
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: <Pine.LNX.4.30.0103082319150.1061-100000@peter.localdomain> <siwv9zeqzy.fsf@daffy.airs.com>
|
|
In-Reply-To: <siwv9zeqzy.fsf@daffy.airs.com>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <zakkr@zf.jcu.cz>
|
|
To: Tom Lane <tgl@sss.pgh.pa.us>
|
|
Cc: pgsql-hackers@postgresql.org
|
|
Subject: Re: [HACKERS] Internationalized error messages
|
|
Message-ID: <20010309085320.A7401@ara.zf.jcu.cz>
|
|
References: <Pine.LNX.4.30.0103082319150.1061-100000@peter.localdomain> <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 <xxx>, 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 <zakkr@zf.jcu.cz>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <pgsql-hackers@postgresql.org>; 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 <t-ishii@sra.co.jp>
|
|
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 <xxx>, 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <peter_e@gmx.net>
|
|
To: <pgsql-hackers@postgresql.org>
|
|
Subject: Re: [HACKERS] Internationalized error messages
|
|
In-Reply-To: <20010308164222.Y624@store.zembu.com>
|
|
Message-ID: <Pine.LNX.4.30.0103091643350.929-100000@peter.localdomain>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <peter_e@gmx.net>
|
|
To: Tom Lane <tgl@sss.pgh.pa.us>
|
|
cc: <pgsql-hackers@postgresql.org>
|
|
Subject: Re: [HACKERS] Internationalized error messages
|
|
In-Reply-To: <4741.984103209@sss.pgh.pa.us>
|
|
Message-ID: <Pine.LNX.4.30.0103091646150.929-100000@peter.localdomain>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <peter_e@gmx.net>
|
|
cc: pgsql-hackers@postgresql.org
|
|
Subject: Re: [HACKERS] Internationalized error messages
|
|
In-reply-to: <Pine.LNX.4.30.0103091646150.929-100000@peter.localdomain>
|
|
References: <Pine.LNX.4.30.0103091646150.929-100000@peter.localdomain>
|
|
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
|
|
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 <tgl@sss.pgh.pa.us>
|
|
Precedence: bulk
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
Status: OR
|
|
|
|
Peter Eisentraut <peter_e@gmx.net> 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <peter_e@gmx.net>
|
|
To: Tom Lane <tgl@sss.pgh.pa.us>
|
|
cc: <pgsql-hackers@postgresql.org>
|
|
Subject: Re: [HACKERS] Internationalized error messages
|
|
In-Reply-To: <6895.984153653@sss.pgh.pa.us>
|
|
Message-ID: <Pine.LNX.4.30.0103091733430.929-100000@peter.localdomain>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <peter_e@gmx.net>
|
|
To: Karel Zak <zakkr@zf.jcu.cz>
|
|
cc: Tom Lane <tgl@sss.pgh.pa.us>, <pgsql-hackers@postgresql.org>
|
|
Subject: Re: [HACKERS] Internationalized error messages
|
|
In-Reply-To: <20010309085320.A7401@ara.zf.jcu.cz>
|
|
Message-ID: <Pine.LNX.4.30.0103091756220.929-100000@peter.localdomain>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <peter_e@gmx.net>
|
|
cc: pgsql-hackers@postgresql.org
|
|
Subject: Re: [HACKERS] Internationalized error messages
|
|
In-reply-to: <Pine.LNX.4.30.0103091733430.929-100000@peter.localdomain>
|
|
References: <Pine.LNX.4.30.0103091733430.929-100000@peter.localdomain>
|
|
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
|
|
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 <tgl@sss.pgh.pa.us>
|
|
Precedence: bulk
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
Status: OR
|
|
|
|
Peter Eisentraut <peter_e@gmx.net> 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <pgsql-hackers@postgresql.org>; 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: <Pine.LNX.4.30.0103091733430.929-100000@peter.localdomain> <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 <andrew@zembu.com>
|
|
Precedence: bulk
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
Status: OR
|
|
|
|
> Peter Eisentraut <peter_e@gmx.net> 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 <tgl@sss.pgh.pa.us> 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 "<subsystem>-<severity>-<error>".
|
|
|
|
--
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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: <Pine.LNX.4.30.0103091733430.929-100000@peter.localdomain> <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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <peter_e@gmx.net>
|
|
To: Tom Lane <tgl@sss.pgh.pa.us>
|
|
cc: <pgsql-hackers@postgresql.org>
|
|
Subject: Re: [HACKERS] Internationalized error messages
|
|
In-Reply-To: <7100.984157522@sss.pgh.pa.us>
|
|
Message-ID: <Pine.LNX.4.30.0103092133380.929-100000@peter.localdomain>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <peter_e@gmx.net>
|
|
cc: pgsql-hackers@postgresql.org
|
|
Subject: Re: [HACKERS] Internationalized error messages
|
|
In-reply-to: <Pine.LNX.4.30.0103092133380.929-100000@peter.localdomain>
|
|
References: <Pine.LNX.4.30.0103092133380.929-100000@peter.localdomain>
|
|
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
|
|
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 <tgl@sss.pgh.pa.us>
|
|
Precedence: bulk
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
Status: OR
|
|
|
|
Peter Eisentraut <peter_e@gmx.net> 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <pgsql-hackers@postgresql.org>; 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 <tgl@sss.pgh.pa.us>
|
|
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 <giles@nemeton.com.au>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <pgsql-hackers@postgresql.org>; 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 <prlw1@newn.cam.ac.uk>
|
|
To: Tom Lane <tgl@sss.pgh.pa.us>
|
|
Cc: Peter Eisentraut <peter_e@gmx.net>, 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: <Pine.LNX.4.30.0103092133380.929-100000@peter.localdomain> <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 <peter_e@gmx.net> 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <zakkr@zf.jcu.cz>
|
|
To: Peter Eisentraut <peter_e@gmx.net>
|
|
Cc: Karel Zak <zakkr@zf.jcu.cz>, Tom Lane <tgl@sss.pgh.pa.us>,
|
|
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> <Pine.LNX.4.30.0103091756220.929-100000@peter.localdomain>
|
|
Mime-Version: 1.0
|
|
Content-Type: text/plain; charset=us-ascii
|
|
User-Agent: Mutt/1.0.1i
|
|
In-Reply-To: <Pine.LNX.4.30.0103091756220.929-100000@peter.localdomain>; 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 <zakkr@zf.jcu.cz>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <peter_e@gmx.net>,
|
|
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
From: Peter Mount <peter@retep.org.uk>
|
|
Subject: Re: [HACKERS] Internationalized error messages
|
|
In-Reply-To: <Pine.LNX.4.30.0103082319150.1061-100000@peter.localdomain>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <peter_e@gmx.net>
|
|
To: Karel Zak <zakkr@zf.jcu.cz>
|
|
cc: Tom Lane <tgl@sss.pgh.pa.us>, <pgsql-hackers@postgresql.org>
|
|
Subject: Re: [HACKERS] Internationalized error messages
|
|
In-Reply-To: <20010312103232.A2268@ara.zf.jcu.cz>
|
|
Message-ID: <Pine.LNX.4.30.0103122013270.1047-100000@peter.localdomain>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <zakkr@zf.jcu.cz>
|
|
To: Peter Eisentraut <peter_e@gmx.net>
|
|
Cc: Karel Zak <zakkr@zf.jcu.cz>, Tom Lane <tgl@sss.pgh.pa.us>,
|
|
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> <Pine.LNX.4.30.0103122013270.1047-100000@peter.localdomain>
|
|
Mime-Version: 1.0
|
|
Content-Type: text/plain; charset=us-ascii
|
|
User-Agent: Mutt/1.0.1i
|
|
In-Reply-To: <Pine.LNX.4.30.0103122013270.1047-100000@peter.localdomain>; 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 <zakkr@zf.jcu.cz>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <peter_e@gmx.net>
|
|
To: PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
Subject: [HACKERS] More on elog and error codes
|
|
Message-ID: <Pine.LNX.4.30.0103192110470.1131-100000@peter.localdomain>
|
|
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(<level>, [<subsys>,?] <code>, 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <peter_e@gmx.net>,
|
|
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
From: Philip Warner <pjw@rhyme.com.au>
|
|
Subject: Re: [HACKERS] More on elog and error codes
|
|
In-Reply-To: <Pine.LNX.4.30.0103192110470.1131-100000@peter.localdomain>
|
|
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(<level>, [<subsys>,?] <code>, 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(<level>, [<subsys>,?] <code>, message...)
|
|
|
|
becomes:
|
|
|
|
elogc(<code> [, 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <pjw@rhyme.com.au>
|
|
cc: Peter Eisentraut <peter_e@gmx.net>,
|
|
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
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 <pjw@rhyme.com.au>
|
|
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 <tgl@sss.pgh.pa.us>
|
|
Precedence: bulk
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
Status: OR
|
|
|
|
Philip Warner <pjw@rhyme.com.au> 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <peter_e@gmx.net>
|
|
To: Philip Warner <pjw@rhyme.com.au>
|
|
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
Subject: Re: [HACKERS] More on elog and error codes
|
|
In-Reply-To: <3.0.5.32.20010320104855.0339d300@mail.rhyme.com.au>
|
|
Message-ID: <Pine.LNX.4.30.0103201726200.1639-100000@peter.localdomain>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <csawtell@xtra.co.nz>
|
|
Organization: At Home
|
|
To: Peter Eisentraut <peter_e@gmx.net>,
|
|
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
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: <Pine.LNX.4.30.0103192110470.1131-100000@peter.localdomain>
|
|
In-Reply-To: <Pine.LNX.4.30.0103192110470.1131-100000@peter.localdomain>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; Tue, 20 Mar 2001 17:10:59 -0500 (EST)
|
|
(envelope-from reedstrm@rice.edu)
|
|
Received: by rice.edu
|
|
via sendmail from stdin
|
|
id <m14fULB-000LGUC@wallace.ece.rice.edu> (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" <reedstrm@rice.edu>
|
|
To: PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
Subject: Re: [HACKERS] More on elog and error codes
|
|
Message-ID: <20010320161057.C1703@rice.edu>
|
|
Mail-Followup-To: PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
References: <Pine.LNX.4.30.0103192110470.1131-100000@peter.localdomain> <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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <peter_e@gmx.net>
|
|
From: Philip Warner <pjw@rhyme.com.au>
|
|
Subject: Re: [HACKERS] More on elog and error codes
|
|
Cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
In-Reply-To: <Pine.LNX.4.30.0103201726200.1639-100000@peter.localdomain>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <csawtell@xtra.co.nz>,
|
|
Peter Eisentraut <peter_e@gmx.net>,
|
|
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
From: Philip Warner <pjw@rhyme.com.au>
|
|
Subject: Re: [HACKERS] More on elog and error codes
|
|
In-Reply-To: <01032109414401.09393@berty>
|
|
References: <Pine.LNX.4.30.0103192110470.1131-100000@peter.localdomain>
|
|
<Pine.LNX.4.30.0103192110470.1131-100000@peter.localdomain>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <peter_e@gmx.net>
|
|
From: Philip Warner <pjw@rhyme.com.au>
|
|
Subject: Re: [HACKERS] More on elog and error codes
|
|
Cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
In-Reply-To: <3.0.5.32.20010321094352.0287ad00@mail.rhyme.com.au>
|
|
References: <Pine.LNX.4.30.0103201726200.1639-100000@peter.localdomain>
|
|
<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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <peter_e@gmx.net>
|
|
To: Philip Warner <pjw@rhyme.com.au>
|
|
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
Subject: Re: [HACKERS] More on elog and error codes
|
|
In-Reply-To: <3.0.5.32.20010321094352.0287ad00@mail.rhyme.com.au>
|
|
Message-ID: <Pine.LNX.4.30.0103212158370.1694-100000@peter.localdomain>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <peter_e@gmx.net>
|
|
From: Philip Warner <pjw@rhyme.com.au>
|
|
Subject: Re: [HACKERS] More on elog and error codes
|
|
Cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
In-Reply-To: <Pine.LNX.4.30.0103212158370.1694-100000@peter.localdomain>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <pjw@rhyme.com.au>
|
|
cc: Peter Eisentraut <peter_e@gmx.net>,
|
|
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
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 <pjw@rhyme.com.au>
|
|
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 <tgl@sss.pgh.pa.us>
|
|
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 <pjw@rhyme.com.au> 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <peter_e@gmx.net>
|
|
From: Philip Warner <pjw@rhyme.com.au>
|
|
Subject: Re: [HACKERS] More on elog and error codes
|
|
Cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <tgl@sss.pgh.pa.us>
|
|
From: Philip Warner <pjw@rhyme.com.au>
|
|
Subject: Re: [HACKERS] More on elog and error codes
|
|
Cc: Peter Eisentraut <peter_e@gmx.net>,
|
|
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
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 <pjw@rhyme.com.au> 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <pjw@rhyme.com.au>
|
|
cc: Peter Eisentraut <peter_e@gmx.net>,
|
|
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
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 <pjw@rhyme.com.au>
|
|
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 <tgl@sss.pgh.pa.us>
|
|
Precedence: bulk
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
Status: OR
|
|
|
|
Philip Warner <pjw@rhyme.com.au> 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <tgl@sss.pgh.pa.us>
|
|
From: Philip Warner <pjw@rhyme.com.au>
|
|
Subject: Re: [HACKERS] More on elog and error codes
|
|
Cc: Peter Eisentraut <peter_e@gmx.net>,
|
|
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
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 <pjw@rhyme.com.au> 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <peter_e@gmx.net>
|
|
To: PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
Subject: [HACKERS] elog with automatic file, line, and function
|
|
Message-ID: <Pine.LNX.4.30.0103192356450.5764-100000@peter.localdomain>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <peter_e@gmx.net>
|
|
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
Subject: Re: [HACKERS] elog with automatic file, line, and function
|
|
In-reply-to: <Pine.LNX.4.30.0103192356450.5764-100000@peter.localdomain>
|
|
References: <Pine.LNX.4.30.0103192356450.5764-100000@peter.localdomain>
|
|
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
|
|
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 <tgl@sss.pgh.pa.us>
|
|
Precedence: bulk
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
Status: OR
|
|
|
|
Peter Eisentraut <peter_e@gmx.net> 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <tgl@sss.pgh.pa.us>
|
|
Cc: Peter Eisentraut <peter_e@gmx.net>,
|
|
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
Subject: Re: [HACKERS] elog with automatic file, line, and function
|
|
References: <Pine.LNX.4.30.0103192356450.5764-100000@peter.localdomain>
|
|
<7932.985044210@sss.pgh.pa.us>
|
|
From: Ian Lance Taylor <ian@airs.com>
|
|
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: <siy9u11dpj.fsf@daffy.airs.com>
|
|
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 <tgl@sss.pgh.pa.us> 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <ian@airs.com>
|
|
cc: Peter Eisentraut <peter_e@gmx.net>,
|
|
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
Subject: Re: [HACKERS] elog with automatic file, line, and function
|
|
In-reply-to: <siy9u11dpj.fsf@daffy.airs.com>
|
|
References: <Pine.LNX.4.30.0103192356450.5764-100000@peter.localdomain> <7932.985044210@sss.pgh.pa.us> <siy9u11dpj.fsf@daffy.airs.com>
|
|
Comments: In-reply-to Ian Lance Taylor <ian@airs.com>
|
|
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 <tgl@sss.pgh.pa.us>
|
|
Precedence: bulk
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
Status: OR
|
|
|
|
Ian Lance Taylor <ian@airs.com> writes:
|
|
> Tom Lane <tgl@sss.pgh.pa.us> 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <ler@lerctr.org>
|
|
To: Tom Lane <tgl@sss.pgh.pa.us>
|
|
Cc: Ian Lance Taylor <ian@airs.com>, Peter Eisentraut <peter_e@gmx.net>,
|
|
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
Subject: Re: [HACKERS] elog with automatic file, line, and function
|
|
Message-ID: <20010319192547.A29294@lerami.lerctr.org>
|
|
References: <Pine.LNX.4.30.0103192356450.5764-100000@peter.localdomain> <7932.985044210@sss.pgh.pa.us> <siy9u11dpj.fsf@daffy.airs.com> <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 <tgl@sss.pgh.pa.us> [010319 18:58]:
|
|
> Ian Lance Taylor <ian@airs.com> writes:
|
|
> > Tom Lane <tgl@sss.pgh.pa.us> 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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: <nnorwitz@yahoo.com>
|
|
Message-ID: <3AB6B5EB.21F2D551@yahoo.com>
|
|
Date: Mon, 19 Mar 2001 20:44:11 -0500
|
|
From: Neal Norwitz <nnorwitz@yahoo.com>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <peter_e@gmx.net>
|
|
To: Tom Lane <tgl@sss.pgh.pa.us>
|
|
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
Subject: Re: [HACKERS] elog with automatic file, line, and function
|
|
In-Reply-To: <7932.985044210@sss.pgh.pa.us>
|
|
Message-ID: <Pine.LNX.4.30.0103212156130.1694-100000@peter.localdomain>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <peter_e@gmx.net>
|
|
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
Subject: Re: [HACKERS] elog with automatic file, line, and function
|
|
In-reply-to: <Pine.LNX.4.30.0103212156130.1694-100000@peter.localdomain>
|
|
References: <Pine.LNX.4.30.0103212156130.1694-100000@peter.localdomain>
|
|
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
|
|
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 <tgl@sss.pgh.pa.us>
|
|
Precedence: bulk
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
Status: OR
|
|
|
|
Peter Eisentraut <peter_e@gmx.net> 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <pgsql-hackers@postgresql.org>; 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 <G8TZMX0Z>; Tue, 20 Mar 2001 17:53:58 +0100
|
|
Message-ID: <11C1E6749A55D411A9670001FA687963368256@sdexcsrv1.f000.d0188.sd.spardat.at>
|
|
From: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
|
|
To: "'Peter Eisentraut'" <peter_e@gmx.net>, Philip Warner <pjw@rhyme.com.au>
|
|
Cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <ZeugswetterA@wien.spardat.at>
|
|
cc: "'Peter Eisentraut'" <peter_e@gmx.net>, Philip Warner <pjw@rhyme.com.au>,
|
|
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
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 <ZeugswetterA@wien.spardat.at>
|
|
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 <tgl@sss.pgh.pa.us>
|
|
Precedence: bulk
|
|
Sender: pgsql-hackers-owner@postgresql.org
|
|
Status: OR
|
|
|
|
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <ler@lerctr.org>
|
|
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 <peter_e@gmx.net>
|
|
CC: Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>,
|
|
=?US-ASCII?Q?=27lockhart=40fourpalms=2Eorg=27?= <lockhart@fourpalms.org>,
|
|
=?US-ASCII?Q?PostgreSQL?= Development <pgsql-hackers@postgresql.org>
|
|
In-Reply-To: <Pine.LNX.4.30.0103201750450.1639-100000@peter.localdomain>
|
|
References: <Pine.LNX.4.30.0103201750450.1639-100000@peter.localdomain>
|
|
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 <peter_e@gmx.net> 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <pgsql-hackers@postgresql.org>; 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 <otto.hirr@olabinc.com> 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: <otto.hirr@olabinc.com>
|
|
From: "Otto A. Hirr, Jr." <otto.hirr@olabinc.com>
|
|
To: "PostgreSQL Development" <pgsql-hackers@postgresql.org>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <lockhart@alumni.caltech.edu>
|
|
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 <pjw@rhyme.com.au>
|
|
Cc: Peter Eisentraut <peter_e@gmx.net>,
|
|
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers@postgresql.org>; 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 <pjw@rhyme.com.au>
|
|
Subject: [HACKERS] Re: More on elog and error codes
|
|
Cc: Peter Eisentraut <peter_e@gmx.net>,
|
|
PostgreSQL Development <pgsql-hackers@postgresql.org>
|
|
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
|
|
|