Re: plpython function problem workaround

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(at)ESI(dot)it