Re: initdb failure (was Re: [GENERAL] sequence's plpgsql) - Mailing list pgsql-hackers

From Jon Jensen
Subject Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Date
Msg-id Pine.LNX.4.58.0309262335210.9886@louche.swelter.net
Whole thread Raw
In response to Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
List pgsql-hackers
On Fri, 26 Sep 2003, Tom Lane wrote:

> I was chewing this over with Bruce on the phone just now, and we refined
> the idea a little.  Some errors (primarily those detected inside the
> datatype input procedures) can be clearly traced to a specific column,
> whereas others (such as too many fields on an input line) really can't
> be nailed down more tightly than a line.  So we were thinking about two
> different flavors of context info:
> 
>     CONTEXT:  COPY tablename, line n, field colname: "column data"
> 
> versus
> 
>     CONTEXT:  COPY tablename, line n: "line data"

Those would be very helpful bits of information.

> where in each case the data display would be truncated at 100 characters
> or so (and would have to be omitted in the COPY BINARY case anyway).
> 
> If you're really concerned about funny characters messing up the report,
> we could imagine replacing them by backslash sequences or some such, but
> I suspect that would create more confusion than it would solve.

I hate to mention it, but would it be useful/non-overkill to make either
of those things (context message maximum length and funny character
escaping) configurable somehow?

Jon


pgsql-hackers by date:

Previous
From: Kris Jurka
Date:
Subject: Re: [JDBC] initdb failure (was Re: [GENERAL] sequence's plpgsql)
Next
From: Bruce Momjian
Date:
Subject: Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)