On Wed, Jan 19, 2005 at 06:28:25PM +1100, Stuart Bishop wrote:
> Michael Fuhr wrote:
> >If Python's behavior is intentional then the newline burden would
> >seem to be on the user or on plpythonu. I think Tom's point is
> >that that's just silly....
>
> Changing this behavior in Python would break backwards compatibility. In
> particular, the exec() function accepts strings that have already been
> unescaped:
>
> >>> exec('print """\n\r\n\r\n"""')
>
> In the above example, the exec function is being passed a string
> containing carridge returns and line feeds - not '\n' and '\r' character
> sequences.
Ofcourse, if the \r is within a literal string, then ofcourse you can't
ignore it. Other languages like C and Perl also maintain any character
within a string. The point is that outside of character strings, there
is no need to consider a \n different form a \r (unless there is a
place in Python where an extra newline changes the meaning).
Sure, you can't just run dos2unix over the code, but within the parser
this is a simple change.
> It is too late for the Python 2.3 series anyway - 2.3.5 is being
> released Jan 26th and there won't be a 2.3.6. If it was championed and
> it decided that the above example is a bug and not a feature and a patch
> produced, it could get into 2.4.1 due April and 2.5+
>
> I suspect this means fixing this problem in plpythonu for 8.1.
I suggest adding to the Release Notes:
User defined functions using the Python language must use the newline
delimiter of the server OS. There is currently no standard way of
determining the newline delimiter of the server. Note this also
affects the portability of pg_dump output.
Hope this helps,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
