Re: plpython function problem workaround - Mailing list pgsql-general

From Sim Zacks
Subject Re: plpython function problem workaround
Date
Msg-id d1674d$1l39$1@news.hub.org
Whole thread Raw
In response to plpython function problem workaround  ("Sim Zacks" <sim@compulab.co.il>)
Responses Re: plpython function problem workaround
List pgsql-general
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
>



pgsql-general by date:

Previous
From: Richard Huxton
Date:
Subject: Re: script variables
Next
From: "FERREIRA William (COFRAMI)"
Date:
Subject: Re: Convert Cursor to array