Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)

Поиск
Список
Период
Сортировка
От Jon Jensen
Тема Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Дата
Msg-id Pine.LNX.4.58.0309262335210.9886@louche.swelter.net
обсуждение исходный текст
Ответ на Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)  (Peter Eisentraut <peter_e@gmx.net>)
Список 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 по дате отправления:

Предыдущее
От: Kris Jurka
Дата:
Сообщение: Re: [JDBC] initdb failure (was Re: [GENERAL] sequence's plpgsql)
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)