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

On Thu, 17 Mar 2005, Michael Fuhr wrote:

> On Thu, Mar 17, 2005 at 09:48:51PM -0500, Tom Lane wrote:
>> Michael Fuhr <mike@fuhr.org> writes:
>>> Line-ending CRs stripped, even inside quotes; mid-line CRs converted
>>> to LF.  Tests done with Python 2.4 on FreeBSD 4.11-STABLE; I wonder
>>> what Python on Windows would do.
>>
>> Unfortunately, I don't think that proves anything, because according
>> to earlier discussion Python will do newline-munging when it reads
>> a file (including a script file).  The question that we have to deal
>> with is what are the rules for a string fed to PyRun_String ... and it
>> seems those rules are not the same.
>
> Marco, you've stated that you're against munging the code because
> "it's not our job to 'fix' data coming from the client."  But I'm
> suggesting that we think about the code in a different way than the
> current implementation does: not as a literal that we pass untouched
> to the Python interpreter, but rather as code that Python would
> munge anyway if it had read that code from a file.  We could still
> store the code exactly as received and have the language handler
> munge it on the fly, as we've discovered it's already doing.
>
> Comments?  Have I overlooked anything?  Could munging CRs have
> effects that a Python programmer wouldn't expect if the same code
> had been read from a file?  Since it mimics Python's own behavior
> with code read from a file, can anybody justify not doing it?

If you put it that way, I'm 100% with you.

Just let me suggest not to mimic its behaviour, but to use the
Real Thing if we manage to. That is, directly use the Universal Line
Support code provided by python itself, so that we don't even have
to think about being compatible.

Unfortunately, I'm new to python embedding. I think I'll ask on
python lists about the function definition code. Actually, we are
kind of a corner case: we ask the user to provide the function
body w/o the initial def declaration. We're treating partial, incomplete
python code and not a well-formed program, so we have to munge it
anyway. I have no idea if and how the python C API lets you
control such low level details. I think what we really want is to
create a callable (anonymous) object from the source of its "body".

I'm experimenting a bit, trying to write a PLy_procedure_compile()
that does not require source munging. I'm aiming at removing the
need for extra indentation. The \r\n thing is another beast, and I'm
not sure it belongs to the same place in our code.

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