Re: plpython function problem workaround

Thank You Michael,

It worked when I tried it on the 3 functions that I have.
I checked the archives for any discussion on the Validator and there wasn't
anything specifically discussing it.
I really didn't find a lot of information about the Validators either, for
example where did you see that a validator function gets the language oid
passed in? The only place I could find it was after I looked at the other
languages installed on my system and saw that they all had the same argument
type passed in.

Sim

"Michael Fuhr" <mike(at)fuhr(dot)org> wrote in message
news:20050314134405(dot)GA20902(at)winnie(dot)fuhr(dot)org(dot)(dot)(dot)
> 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/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>