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)
Re: initdb failure (was Re: [GENERAL] sequence's plpgsql) |
Список | 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 по дате отправления: