On Fri, Mar 09, 2001 at 03:48:33PM -0500, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> 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
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 broadcas
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 ope
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 s
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 impo
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 t
Peter Eisentraut <[EMAIL PROTECTED]> 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 th
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 #
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 su
> Peter Eisentraut <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> spake:
> I object to writing "2200G" how
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 [EMAIL PROTECTED] http://yi.org/peter-e
Peter Eisentraut <[EMAIL PROTECTED]> 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 o
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 o
Peter Eisentraut <[EMAIL PROTECTED]> 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 t
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 fra
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
> numer
> For transaltion to other languages I not sure with gettext() stuff on
> backend -- IMHO better (faster) solution will postgres system catalog
> with it.
>
> May be add new command too: SET MESSAGE_LANGUAGE TO , because
> wanted language not must be always same as locale setting.
In the multi
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 fo
> 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
On Thu, Mar 08, 2001 at 09:00:09PM -0500, Tom Lane wrote:
> [EMAIL PROTECTED] (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
> 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.
[EMAIL PROTECTED] (Nathan Myers) writes:
> Similar approaches have been tried frequently, and even enshrined
> in standards (e.g. POSIX catgets), but
On Thu, Mar 08, 2001 at 11:49:50PM +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
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> 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
>
> elog(ERROR, "disaster struck");
>
> you'd write
>
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 relia
24 matches
Mail list logo
