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 id
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('
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 rel
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,
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 s
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 one-true
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, 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 writte
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
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 the
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, ins
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, sinc
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
-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 He
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. Not
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 Pyt
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
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 seq
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 brea
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:
Ther
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 suppo
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 2
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
> followe
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 en
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 wit
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 s
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 th
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 pg
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 wh
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 b
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.
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 r
32 matches
Mail list logo
