On Tue, 29 Mar 2005, Marco Colombo wrote:
# escapes (expanded by PostgreSQL)
q3 = r"select 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 cut&paste error
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 text
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 t
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:
http://archives.p
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 str
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
http://www.f
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, 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 app
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 wou
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 compati
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 Thu, 17 Mar 2005, Tom Lane wrote:
Martijn van Oosterhout 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?
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:
>
> http://cvs.sourceforge.net/viewcvs.py/python/pytho
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 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.
>
> Unfortunate
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 d
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.
Martijn van Oosterhout 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 that once you
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 cod
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) a
[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 differe
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
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
> Postgre
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
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, t
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 h
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
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, 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, 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? T
"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
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
>
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 everyt
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:[EMAI
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%'")
r
"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
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 ra
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
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 anybo
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
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
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
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 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'
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 ju
47 matches
Mail list logo
