Re: plpython function problem workaround

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
>