Now that I think about it, FTP programs currently do this when they transfer ASCII files. If you have a planned CR in your program and FTP from mac to windows the CR becomes a CRLF and if you FTP from mac to unix the CR changes to an LF.
"Sim Zacks" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I've been looking at the possibility of having a planned CR in the source > code and I don't see a case where it would happen. > I tried this function, as an example: > create or replace function crtest() returns int as > $$ > x=plpy.execute("select * from pg_proc where prosrc like '%\r%'") > return x.nrows() > $$ language 'plpythonu' > > and it considered the \r to be text and not a CR. Therefore the update > function removed the CR at the end of the line but ignored the \r that was > specifically mentioned. > > Is there any case that someone can think of where an actual CR, not a > textual representation of it, would purposefully be put into the code? > > Sim > > > "Tom Lane" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > "Sim Zacks" <[EMAIL PROTECTED]> writes: > > > I don't think that this type of solution should be discussed as an > official > > > patch. > > > If it was, I would recommend solving the problem in source code when the > > > function is passed to the translator. > > > > Indeed, but first we need to work out what the necessary translation is. > > A hack using a VALIDATOR function isn't an unreasonable way to prototype > > the conversion logic. > > > > regards, tom lane > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > > > > ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
