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

On Wed, 16 Mar 2005, Michael Fuhr wrote:

> [I've changed the Subject back to the thread that started this
> discussion.]
>
> On Wed, Mar 16, 2005 at 05:52:02PM +0100, Marco Colombo wrote:
>
>> I'm against to any on-the-fly conversion, now.
>> I don't like the idea of PostgreSQL accepting input in one form
>> (\r\n) and providing output in a different form (\n). Also think of
>> a function definition with mixed \r\n and \n lines: we'd have no way
>> to reconstruct the original input.
>
> Yeah, that's a reasonable argument against modifying the function
> source code before storing it in pg_proc.  But I expect this problem
> will come up again, and some people might not care about being able
> to reconstruct the original input if it's just a matter of stripped
> carriage returns, especially if the function logic doesn't use
> literal carriage return characters that would be missed.  For those
> people, the validator hack might be an acceptable way to deal with
> a client interface that inserts carriage returns that the programmer
> didn't intend anyway.  Not necessarily as part of the core PostgreSQL
> code or even distributed with PostgreSQL, but as something they
> could install if they wanted to.

Agreed.

>> I think we should just state that text used for function definitions
>> is \n-delimited.  Some languages may accept \r\n as well, but that's
>> undocumented side effect, and bad practice.
>
> Whether it's an "undocumented side effect" depends on the language,
> and whether it's bad practice is a matter of opinion.

Sure. I mean, we may just state that, per spec. Program data
should be \n-delimeted, full stop. It sounds sensible to me.
Just put it somewhere in the docs, problem solved. We're loosing
nothing. I'm just proposing to add that to the docs/specs.

>                                                       In any case,
> that's the language's concern and not something PostgreSQL should
> judge or enforce.  PostgreSQL shouldn't have to know or care about a
> procedural language's syntax -- a function's source code should be an
> opaque object that PostgreSQL stores and passes to the language's
> handler without caring about its contents.  Syntax enforcement should
> be in the language's validator or handler according to the language's
> own rules.

That's what we do now. My point being it's not our job to "fix" data
coming from the client. If a client app creates a plpython function
the wrong way, fix it. Why should we place a paperbag on a client bug?

> Speaking of code munging and syntax enforcement, have a look at this:
>
> CREATE FUNCTION foo() RETURNS text AS $$
> return """line 1
> line 2
> line 3
> """
> $$ LANGUAGE plpythonu;
>
> SELECT foo();
>           foo
> --------------------------
> line 1
>        line 2
>        line 3
>
> (1 row)
>
> Eh?  Where'd those leading tabs come from?  Why, they came from
> PLy_procedure_munge_source() in src/pl/plpython/plpython.c:
>
>    mrc = PLy_malloc(mlen);
>    plen = snprintf(mrc, mlen, "def %s():\n\t", name);
>    Assert(plen >= 0 && plen < mlen);
>
>    sp = src;
>    mp = mrc + plen;
>
>    while (*sp != '\0')
>    {
>        if (*sp == '\n')
>        {
>            *mp++ = *sp++;
>            *mp++ = '\t';
>        }
>        else
>            *mp++ = *sp++;
>    }
>    *mp++ = '\n';
>    *mp++ = '\n';
>    *mp = '\0';
>
> How about them apples?  The PL/Python handler is already doing some
> fixup behind the scenes (and potentially causing problems, as the
> example illustrates).

OMG! It's indenting the funtion body. I think you can't do that
w/o being syntax-aware. I'm not familiar with the code, why is it
adding a 'def' in front of it at all? I undestand that once you do
it you'll have to shift the code by an indentation level.

.TM.
--
       ____/  ____/   /
      /      /       /            Marco Colombo
     ___/  ___  /   /              Technical Manager
    /          /   /             ESI s.r.l.
  _____/ _____/  _/               Colombo@ESI.it