Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation.
Date
Msg-id 24035.1339536406@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation.  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> I am not sure about the idea of letting the detail run to the end of the
> line; that would be problematic should the line be long (there might not
> be newlines in the literal at all, which is not that unusual).  I think
> it should be truncated at, say, 76 chars or so.

Yeah, I was wondering about trying to provide a given amount of context
instead of fixing it to "one line".  We could do something like

(1) back up N characters;
(2) find the next newline, if there is one at least M characters before
the error point;
(3) print from there to the error point.

This would give between M and N characters of context, except when the
error point is less than M characters from the start of the input.  Not
sure how to display such text together with a line number though; with a
multi-line fragment it would not be obvious which part the line number
refers to.  (Backing up over multibyte data might be a bit complicated
too, but I assume we can think of something workable for that.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers)
Next
From: "Kevin Grittner"
Date:
Subject: Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers)