Re: plpython function problem workaround

On Mon, Mar 14, 2005 at 10:54:22AM -0500, Tom Lane wrote:

> The proposed hack seems far too simplistic to me ... what of CRs that
> are deliberately included in string literals?

Yeah, I meant to mention that; I think it's been brought up before
in related threads. The programmer would need to be aware of that
issue and allow for it. It doesn't seem to be a problem if you use
\r escape sequences in a dollar-quoted function body or if you use
\\r in single quotes -- is there any case where those sequences
might get converted to literal CRs? Third-party software like user
interfaces might be problematic, but what about PostgreSQL itself
and its "official" tools (psql, pg_dump, etc.)?

> I don't know Python at all, so I don't know how complicated its lexical
> structure is, but ISTM you'd at least need enough smarts to distinguish
> literals from unquoted whitespace.

The example I posted was merely that: an example. I was more
interested in whether abusing the validator mechanism would work
or if it might have subtle problems. A function that understands
the Python grammar is left as an exercise for the reader.

> The other small fly in the ointment is that when the server is running
> on Windows, I suppose we would have to *put in* rather than remove CRs.

Would we? My understanding is that code passed to PyRun_String()
and friends must be free of line-ending CRs on all platforms, and
that the code that reads a "normal" Python script takes care of
that (i.e., normalizes line endings to be LF only). Can anybody
confirm or deny?

> Sim probably doesn't care about that case, but we couldn't accept an
> official patch that doesn't handle it.

I wasn't proposing a patch, at least not yet. Just throwing out
an idea that somebody might be able to build on.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/