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

From Bruce Momjian
Subject Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Date
Msg-id 200309270103.h8R134x25063@candle.pha.pa.us
Whole thread Raw
In response to Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)  (Jon Jensen <jon@endpoint.com>)
List pgsql-hackers
Jon Jensen wrote:
> 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?

Overkill.  Sorry.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Jon Jensen
Date:
Subject: Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Next
From: Bruce Momjian
Date:
Subject: Separate shared_buffer management process