Re: plpython function problem workaround

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" <sim@compulab.co.il> wrote in message
news:d1674d$1l39$1@news.hub.org...
> 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" <tgl@sss.pgh.pa.us> wrote in message
> news:3279.1110868888@sss.pgh.pa.us...
> > "Sim Zacks" <sim@compulab.co.il> 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 majordomo@postgresql.org
> >
>
>