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

Andrew Dunstan wrote:
> Bruce Momjian wrote:
>
> >I posted on that a few minutes ago. Yea, we can drop it, but we risk
> >eating carraige returns as data values. I am not sure how consistently
> >we output literal carriage returns in old dumps, nor how many apps
> >produce on literal carriage returns in COPY. If we conditionally eat
> >them, we run the risk of discarding some of their data without warning.
> >Perhaps we can throw a warning rather than an error, and adjust initdb
> >to be consistent.
> >
> >
> >
>
> Would the best longterm solution be to require escaping CR in a data
> value? (Yes I know this might cause backwards compatibility problems, at
> least for a while).

Yes, we do have that documented, but we supported it in earlier
releases, so we can't be sure who is using it, and it probably exists in
older dumps.

The particular problem is not literal carriage returns, which we don't
support any more, but carriage returns that happen to be at the end of
the line, right up against \n. If we relax this, we will conditionally
strip off the \r.

In fact, we can do that now:

create table xx(text);

Right now, if all the column value end with \r, we will silently eat it.
But if some have \r and some do not, we will throw an error. (Above,
when I say \r, I mean literal carriage return, not the "\r" string,
which we have always handled cleanly.

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