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

From Michael Fuhr
Subject Re: plpython function problem workaround
Date
Msg-id 20050314134405.GA20902@winnie.fuhr.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
On Mon, Mar 14, 2005 at 02:37:00PM +0200, Sim Zacks wrote:

> I worked around the plpython problem that doesn't allow scripts created on
> Windows to be run on the *nix server with the following statement.
>     update pg_proc set prosrc=replace(prosrc,chr(13),'') where prolang=87238
> --plpythonu's oid in my setup is 87238. I don't know if that is a standard
> or just on mine.

The oid is arbitrary, so you should get it via a (sub)query instead
of hardcoding it.

> Is there a way to automate that script every time a plpythonu function is
> created?
> I tried writing a trigger on the pg_proc table but it wouldn't let me:

Hmmm...plpythonu doesn't install a VALIDATOR function.  I wonder
if you could exploit that?  This is just a brainstorm, but the
following worked for me in trivial tests:

CREATE FUNCTION fixpython(funcoid oid) RETURNS void AS $$
BEGIN
    UPDATE pg_proc SET prosrc = replace(prosrc, chr(13), '')
     WHERE oid = funcoid;

    RETURN;
END;
$$ LANGUAGE plpgsql VOLATILE STRICT;

UPDATE pg_language SET lanvalidator = 'fixpython'::regproc
 WHERE lanname = 'plpythonu';

Are there any problems with doing this?  Is a VALIDATOR function
permitted to modify the function it's validating?  This wouldn't
work if plpythonu ever installs a VALIDATOR, but you might be able
to use it until such time (barring objections about why it's a Bad
Idea, that is).

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

pgsql-general by date:

Previous
From: Mark Rae
Date:
Subject: Re: prelimiary performance comparison pgsql vs mysql
Next
From: go
Date:
Subject: free space map settings