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.
_____/ _____/ _/ [EMAIL PROTECTED]---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
