On Fri, 21 Jan 2005, Martijn van Oosterhout wrote:
On Fri, Jan 21, 2005 at 12:02:09PM +0100, Marco Colombo wrote:
On Fri, 21 Jan 2005, Greg Stark wrote:
I don't think it's reasonable for pg_dump to think about converting
data from one language to another. It's important for pg_dump to
restore an
On Fri, 2005-01-21 at 01:30 -0500, Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
Egads. So the set of valid Python programs is different depending on what
platform you're on? That's just, uhm, insane.
No quibble here.
Funny discussion. Did you ever try a shell script written on
On Fri, 21 Jan 2005, Greg Stark wrote:
Marco Colombo [EMAIL PROTECTED] writes:
Exaclty. Or, one could say: the standard text format is the one the
platform you are running on dictates. Which is what python does.
Egads. So the set of valid Python programs is different depending on what
platform
On Fri, 21 Jan 2005, Stuart Bishop wrote:
This is currently being discussed on python-dev:
http://mail.python.org/pipermail/python-dev/2005-January/051203.html
It looks like my earlier concerns were unwarrented - current consensus seems
to be to transform line endings in the string to the
On Fri, Jan 21, 2005 at 12:02:09PM +0100, Marco Colombo wrote:
On Fri, 21 Jan 2005, Greg Stark wrote:
I don't think it's reasonable for pg_dump to think about converting
data from one language to another. It's important for pg_dump to
restore an identical database. Having it start with special
On Fri, Jan 21, 2005 at 12:02:09 +0100,
Marco Colombo [EMAIL PROTECTED] wrote:
On Fri, 21 Jan 2005, Greg Stark wrote:
Anyway, think of floats. If you want do to FP maths fast, you need to use
the native format supported by the CPU. When you dump, you get a text
form of the FP number, and
On Fri, 21 Jan 2005, Bruno Wolff III wrote:
On Fri, Jan 21, 2005 at 12:02:09 +0100,
If you are going to another system that uses the same floating point
representation, you should get the same number. pg_dump writes out
enough digits that the exact number can be recovered when the dump
has been
Stuart Bishop [EMAIL PROTECTED] writes:
Changing this behavior in Python would break backwards compatibility.
Nonsense. It would not affect the behavior of any script that was
accepted before.
In particular, the exec() function accepts strings that have already been
unescaped:
exec('print
On Wed, Jan 19, 2005 at 07:06:49PM -0500, Frank D. Engel, Jr. wrote:
Uh, does the Python doc specify platform line endings, or normal
(\n) line endings? It sounded to me like it always wanted the
UNIX-style \n line endings, so that using those would result in
portability...
That's the
On Wed, 19 Jan 2005, Martijn van Oosterhout wrote:
On Wed, Jan 19, 2005 at 12:20:23PM +0100, Marco Colombo wrote:
I think you're missing that vendors define what a 'text file' is on their
platform, not Guido. Guido just says that a Python program is a text file,
which is a very sound decision,
Marco Colombo [EMAIL PROTECTED] writes:
Exaclty. Or, one could say: the standard text format is the one the
platform you are running on dictates. Which is what python does.
Egads. So the set of valid Python programs is different depending on what
platform you're on? That's just, uhm, insane.
Greg Stark [EMAIL PROTECTED] writes:
Egads. So the set of valid Python programs is different depending on what
platform you're on? That's just, uhm, insane.
No quibble here.
Incidentally, are we sure we've diagnosed this correctly? I'm discussing this
with some Python developers and they're
Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
Egads. So the set of valid Python programs is different depending on what
platform you're on? That's just, uhm, insane.
No quibble here.
Incidentally, are we sure we've diagnosed this correctly? I'm discussing this
with some Python developers
On Wed, Jan 19, 2005 at 06:28:25PM +1100, Stuart Bishop wrote:
Michael Fuhr wrote:
If Python's behavior is intentional then the newline burden would
seem to be on the user or on plpythonu. I think Tom's point is
that that's just silly
Changing this behavior in Python would break
On Tue, 18 Jan 2005, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
http://docs.python.org/ref/physical.html
A physical line ends in whatever the current platform's convention
is for terminating lines. On Unix, this is the ASCII LF (linefeed)
character. On Windows, it is the ASCII
On Wed, Jan 19, 2005 at 12:20:23PM +0100, Marco Colombo wrote:
On Tue, 18 Jan 2005, Tom Lane wrote:
followed by linefeed). On Macintosh, it is the ASCII CR (return)
character.
Seems like Guido has missed a bet here: namely the case of a script
generated on one platform and fed to an
Martijn van Oosterhout wrote:
On Wed, Jan 19, 2005 at 06:28:25PM +1100, Stuart Bishop wrote:
Michael Fuhr wrote:
If Python's behavior is intentional then the newline burden would
seem to be on the user or on plpythonu. I think Tom's point is
that that's just silly
Changing this behavior in
On Thu, Jan 20, 2005 at 09:50:43AM +1100, Stuart Bishop wrote:
Martijn van Oosterhout wrote:
User defined functions using the Python language must use the newline
delimiter of the server OS. There is currently no standard way of
determining the newline delimiter of the server. Note this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Uh, does the Python doc specify platform line endings, or normal
(\n) line endings? It sounded to me like it always wanted the
UNIX-style \n line endings, so that using those would result in
portability...
On Jan 19, 2005, at 6:03 PM, Alvaro
On Tue, Jan 18, 2005 at 01:24:31AM -0500, Tom Lane wrote:
It seems odd that in today's climate the Python interpreter
would not cope well with Windows-style newlines. Maybe there is some
configuration issue with Python itself?
http://docs.python.org/ref/physical.html
A physical line ends
Michael Fuhr [EMAIL PROTECTED] writes:
http://docs.python.org/ref/physical.html
A physical line ends in whatever the current platform's convention
is for terminating lines. On Unix, this is the ASCII LF (linefeed)
character. On Windows, it is the ASCII sequence CR LF (return
followed by
Actually universal newline support seems to be covered by the following PEP
and is present in the version of Python(2.3) I am running.
http://www.python.org/peps/pep-0278.txt
I would tend to agree with Hong Yuan that the problem exists in plpythonu's
handling of newlines.
On Tuesday 18 January
On Tue, Jan 18, 2005 at 07:34:59PM -0800, Adrian Klaver wrote:
Actually universal newline support seems to be covered by the following PEP
and is present in the version of Python(2.3) I am running.
http://www.python.org/peps/pep-0278.txt
I see the following in the PEP:
There is no support
Michael Fuhr wrote:
On Tue, Jan 18, 2005 at 07:34:59PM -0800, Adrian Klaver wrote:
Actually universal newline support seems to be covered by the following PEP
and is present in the version of Python(2.3) I am running.
http://www.python.org/peps/pep-0278.txt
I see the following in the PEP:
Hi,
I am biwildered at how to create a multi-line plpython function in
Postgres. When I create the function in one line like this:
CREATE or REPLACE FUNCTION circ (float)
RETURNS float AS 'from math import pi; return 2*pi*args[0]' LANGUAGE
plpythonu;
and then use SELECT circ(1) to test it, it
On Monday 17 January 2005 01:54 am, Hong Yuan wrote:
I entered the multilineversion of this function exactly as written here and it
ran properly. This was with version 8.0 of Postgres. You might want to do
a /df+ circ in psql to see if your editor is putting a space at the beginning
of line 2.
Adrian Klaver wrote:
On Monday 17 January 2005 01:54 am, Hong Yuan wrote:
I entered the multilineversion of this function exactly as written here and it
ran properly. This was with version 8.0 of Postgres. You might want to do
a /df+ circ in psql to see if your editor is putting a space at the
Hong Yuan [EMAIL PROTECTED] writes:
I suppose there are some invisible characters inserted into the function
body by pgAdmin.
Seems like it must be. You could try pg_dump'ing both versions of the
function and comparing the output files byte-by-byte.
Be sure to let the pgAdmin guys know what
Tom Lane wrote:
Hong Yuan [EMAIL PROTECTED] writes:
I suppose there are some invisible characters inserted into the function
body by pgAdmin.
Seems like it must be. You could try pg_dump'ing both versions of the
function and comparing the output files byte-by-byte.
Be sure to let the
Hong Yuan [EMAIL PROTECTED] writes:
Following your direction, I did a byte-by-byte comparasion of the dump
files of the two different version. The sole difference is that in the
working version, the line break is represented the unix way as one 0x0a,
while in the non-working version the
Tom Lane wrote:
Now that you say that, I seem to recall that this has been reported
before. It seems odd that in today's climate the Python interpreter
would not cope well with Windows-style newlines. Maybe there is some
configuration issue with Python itself?
I found a thread on exactly the
On Tue, Jan 18, 2005 at 01:24:31AM -0500, Tom Lane wrote:
Now that you say that, I seem to recall that this has been reported
before. It seems odd that in today's climate the Python interpreter
would not cope well with Windows-style newlines. Maybe there is some
configuration issue with
32 matches
Mail list logo
