Martijn van Oosterhout wrote:
> 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.
Oh - I had confused myself. Your point about dos2unix shows that
plpythonu might not be able to do this 'correctly' unless it understands
a good chunk of Python syntax. It could do it 'good enough' if that is
acceptible.
I'll take this to python-dev, but unfortunately I think my comment below
about the 2.3 series still stands unless higher powers believe this is a
show stopper.
>>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.
I don't see how it affects the portability of pg_dump. If you have a
working Python function (with unix line endings), won't pg_dump dump the
source with unix line endings?
--
Stuart Bishop <stuart@stuartbishop.net>
http://www.stuartbishop.net/
