The only ?issue? that I have found with it is similar to an issue I
posted about multiline in general, which does not seem to be
considered a bug.
I would say if it is documented that any newlines in a python
function, including embedded newlines, are *NIX newlines no matter
what operating system
On Tue, 29 Mar 2005, Sim Zacks wrote:
The only ?issue? that I have found with it is similar to an issue I
posted about multiline in general, which does not seem to be
considered a bug.
I've posted similar concerns in the past. The whole point is that
there are two possible approaches:
1) treat
On Tue, 29 Mar 2005, Marco Colombo wrote:
# escapes (expanded by PostgreSQL)
q3 = rselect count(f1) from test1 where f1 = 'this is a multi line
string\r\nline2\r\nline3\r\n'
curs.execute(q3)
^^
This line (no. 28) is useless (but harmless), please ignore it
(just a cutpaste error).
On Fri, Mar 18, 2005 at 10:12:05PM -0700, Michael Fuhr wrote:
I just submitted a small patch to convert CRLF = LF, CR = LF.
This patch is in 8.0.2beta1, so PL/Python users might want to test
it before 8.0.2 is released. See the recent 8.0.2 Beta Available
announcement:
Sorry it took me so long to respond. I've been out for a couple days.
While certain things may be permissible in a language, I think it is also
important to look at the context at which the language is applied and make a
determination if it will practically turn up in relevant code. If the answer
On Fri, 18 Mar 2005, Tom Lane wrote:
Marco Colombo [EMAIL PROTECTED] writes:
Right now I'm parsing the string first, changing the resulting
parse tree adding missing nodes (def, INDENT, DEINDENT) and
then compiling it.
Hmmm ... is this really going to be simpler or more robust than lexing
the
On Thu, 17 Mar 2005, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, Mar 17, 2005 at 01:03:36PM +0100, Marco Colombo wrote:
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
On Thu, 17 Mar 2005, Michael Fuhr wrote:
On Thu, Mar 17, 2005 at 09:48:51PM -0500, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] 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
On Fri, Mar 18, 2005 at 11:34:46AM +0100, Marco Colombo wrote:
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
Michael Fuhr [EMAIL PROTECTED] writes:
On Fri, Mar 18, 2005 at 12:35:07AM -0500, Tom Lane wrote:
So that part of it can be solved fairly easily.
Should I submit a patch? It should be only a few additional lines
in PLy_procedure_munge_source(). Would you apply it only to HEAD,
or would it
On Fri, 18 Mar 2005, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
On Fri, Mar 18, 2005 at 12:35:07AM -0500, Tom Lane wrote:
So that part of it can be solved fairly easily.
Should I submit a patch? It should be only a few additional lines
in PLy_procedure_munge_source(). Would you
Marco Colombo [EMAIL PROTECTED] writes:
Right now I'm parsing the string first, changing the resulting
parse tree adding missing nodes (def, INDENT, DEINDENT) and
then compiling it.
Hmmm ... is this really going to be simpler or more robust than lexing
the string carefully enough to insert
On Fri, Mar 18, 2005 at 10:33:01AM -0500, Tom Lane wrote:
I think it would be reasonable to back-patch a small fix to convert CRLF.
The sort of rewrite Marco is considering, I wouldn't back-patch.
I just submitted a small patch to convert CRLF = LF, CR = LF.
--
Michael Fuhr
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)
On Thu, Mar 17, 2005 at 01:03:36PM +0100, Marco Colombo wrote:
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
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, Mar 17, 2005 at 01:03:36PM +0100, Marco Colombo wrote:
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
On Thu, Mar 17, 2005 at 10:49:24AM -0500, Tom Lane wrote:
Seems like we have to upgrade that thing to have a complete
understanding of Python lexical rules --- at least enough to know where
the line boundaries are. Which is pretty much exactly the same as
knowing which CRs to strip out. So
Michael Fuhr [EMAIL PROTECTED] 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
On Thu, Mar 17, 2005 at 09:48:51PM -0500, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] 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
Michael Fuhr [EMAIL PROTECTED] writes:
Apparently any CR or LF is considered a line
ending in an ordinary Python script, with CR and CRLF normalized
to LF before being passed to the interpreter, so I'm thinking that
a Python programmer wouldn't expect to be able to embed CRs in a
string
On Fri, Mar 18, 2005 at 12:35:07AM -0500, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
then concerns about CR conversions potentially messing up a user's
strings might be unfounded.
Yeah, it looks like you are right:
On Tue, Mar 15, 2005 at 02:50:06PM -0700, Michael Fuhr wrote:
On Tue, Mar 15, 2005 at 03:41:37PM +, Ragnar Hafstað wrote:
actually, perl scripts with \r\n line endings will run just fine in
unix/linux.
Indeed, and PL/Perl doesn't care. I just tested several PLs with
PostgreSQL
On Tue, Mar 15, 2005 at 03:41:37PM +, Ragnar Hafstað wrote:
On Tue, 2005-03-15 at 07:33 -0600, David wrote:
[about the line-termination problem in plpython]
I'd like to insert one note here. While I'm not particularly familiar
with either perl or python, when I encountered the
[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
I've been looking at the possibility of having a planned CR in the source
code and I don't see a case where it would happen.
I tried this function, as an example:
create or replace function crtest() returns int as
$$
x=plpy.execute(select * from pg_proc where prosrc like '%\r%')
Now that I think about it, FTP programs currently do this when they transfer
ASCII files.
If you have a planned CR in your program and FTP from mac to windows the CR
becomes a CRLF and if you FTP from mac to unix the CR changes to an LF.
Sim Zacks [EMAIL PROTECTED] wrote in message
news:[EMAIL
The following is how I understand it, but please let's delay further
discussion until someone tests the program under Windows.
On Mon, 14 Mar 2005, Michael Fuhr wrote:
Hmmm...I think that would be inconsistent with previous reports.
For example, in the following message, the poster said that
On Tue, Mar 15, 2005 at 08:09:47AM +0200, Sim Zacks wrote:
I don't think that this type of solution should be discussed as an official
patch.
If it was, I would recommend solving the problem in source code when the
function is passed to the translator. That way each platform could fix the
Sim Zacks [EMAIL PROTECTED] writes:
I've been looking at the possibility of having a planned CR in the source
code and I don't see a case where it would happen.
Does python actually disallow newlines in string literals? That is
x = 'foo
bar'
Whether you think this is good style is
On Tue, Mar 15, 2005 at 09:46:54AM -0500, Tom Lane wrote:
Sim Zacks [EMAIL PROTECTED] writes:
I've been looking at the possibility of having a planned CR in the source
code and I don't see a case where it would happen.
Does python actually disallow newlines in string literals? That is
On Tue, 2005-03-15 at 07:33 -0600, David wrote:
[about the line-termination problem in plpython]
I'd like to insert one note here. While I'm not particularly familiar
with either perl or python, when I encountered the referred-to thread
regarding Windows/Unix newline incompatibilities in
On Tue, 15 Mar 2005, Tom Lane wrote:
Sim Zacks [EMAIL PROTECTED] writes:
I've been looking at the possibility of having a planned CR in the source
code and I don't see a case where it would happen.
Does python actually disallow newlines in string literals? That is
x = 'foo
bar'
Whether
On Tue, Mar 15, 2005 at 01:40:23PM +0100, Marco Colombo wrote:
On Mon, 14 Mar 2005, Michael Fuhr wrote:
Hmmm...I think that would be inconsistent with previous reports.
For example, in the following message, the poster said that everything
(PostgreSQL, pgAdmin) was running on Windows 2003:
On Tue, 15 Mar 2005, Michael Fuhr wrote:
[...]
That somebody was me.
Ok, sorry.
I'll postpone commenting on the rest until we find out how the
example programs run on Windows. If nobody follows up here then
maybe I'll wander over to comp.lang.python.
Yeah, there's no point in discussing until we
On Tue, Mar 15, 2005 at 06:03:01PM +0100, Marco Colombo wrote:
On Tue, 15 Mar 2005, Michael Fuhr wrote:
I'll postpone commenting on the rest until we find out how the
example programs run on Windows. If nobody follows up here then
maybe I'll wander over to comp.lang.python.
Yeah, there's
On Tue, Mar 15, 2005 at 03:41:37PM +, Ragnar Hafstað wrote:
actually, perl scripts with \r\n line endings will run just fine in
unix/linux.
Indeed, and PL/Perl doesn't care. I just tested several PLs with
PostgreSQL 8.0.1 on Solaris 9 and here are the results:
PL/pgSQL CRLF ok
PL/Perl
On Tue, Mar 15, 2005 at 06:03:01PM +0100, Marco Colombo wrote:
On Tue, 15 Mar 2005, Michael Fuhr wrote:
I'll postpone commenting on the rest until we find out how the
example programs run on Windows. If nobody follows up here then
maybe I'll wander over to comp.lang.python.
Yeah, there's
I worked around the plpython problem that doesn't allow scripts created on
Windows to be run on the *nix server with the following statement.
update pg_proc set prosrc=replace(prosrc,chr(13),'') where prolang=87238
--plpythonu's oid in my setup is 87238. I don't know if that is a standard
or
On Mon, Mar 14, 2005 at 02:37:00PM +0200, Sim Zacks wrote:
I worked around the plpython problem that doesn't allow scripts created on
Windows to be run on the *nix server with the following statement.
update pg_proc set prosrc=replace(prosrc,chr(13),'') where prolang=87238
--plpythonu's
Thank You Michael,
It worked when I tried it on the 3 functions that I have.
I checked the archives for any discussion on the Validator and there wasn't
anything specifically discussing it.
I really didn't find a lot of information about the Validators either, for
example where did you see that a
On Mon, Mar 14, 2005 at 04:08:09PM +0200, Sim Zacks wrote:
I checked the archives for any discussion on the Validator and there wasn't
anything specifically discussing it.
I really didn't find a lot of information about the Validators either, for
example where did you see that a validator
Michael Fuhr [EMAIL PROTECTED] writes:
Are there any problems with doing this? Is a VALIDATOR function
permitted to modify the function it's validating?
Well, it's not *supposed* to, but the tuple is already stored so I
guess an UPDATE on it will work. At the moment.
This wouldn't work if
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
On Mon, 14 Mar 2005, Michael Fuhr wrote:
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
On Mon, Mar 14, 2005 at 08:14:42PM +0100, Marco Colombo wrote:
On Mon, 14 Mar 2005, Michael Fuhr wrote:
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
I don't think that this type of solution should be discussed as an official
patch.
If it was, I would recommend solving the problem in source code when the
function is passed to the translator. That way each platform could fix the
code to work with as is needed and the code would be portable.
I
Sim Zacks [EMAIL PROTECTED] writes:
I don't think that this type of solution should be discussed as an official
patch.
If it was, I would recommend solving the problem in source code when the
function is passed to the translator.
Indeed, but first we need to work out what the necessary
47 matches
Mail list logo
