On Sat, Jul 23, 2005 at 10:38:59PM -0400, Tom Lane wrote:
Well, if it is just a Python version issue then all we need do is add
a variant expected-output file to match. I was just expressing a
desire to know that for sure before we wallpaper over the symptom...
I just built Python 2.3 and it
Michael Fuhr said:
I just built Python 2.3 and it does indeed format the error differently
than later versions (the format appears to have changed in 2.3.1):
[snip]
I've attached two new files that should go in the plpython directory:
resultmap
expected/plpython_error_py23.out
A problem
Michael Fuhr [EMAIL PROTECTED] writes:
A problem with this patch is that it assumes a version of Python
based on the OS, which might clean up the current buildfarm but
that isn't really correct. Is there a better way to handle this?
Yes --- just let pg_regress deal with it as if it were a
On Sun, Jul 24, 2005 at 08:40:42AM -0500, Andrew Dunstan wrote:
This is completely unnecessary - pg_regress has an alternative result
mechanism that doesn't rely on a resultmap file. Just name your alternative
result file foo_n.out instead of foo.out, for some n in [0-9]. In this case,
call
Michael Fuhr wrote:
On Sun, Jul 24, 2005 at 08:40:42AM -0500, Andrew Dunstan wrote:
This is completely unnecessary - pg_regress has an alternative result
mechanism that doesn't rely on a resultmap file. Just name your alternative
result file foo_n.out instead of foo.out, for some n in
Andrew Dunstan [EMAIL PROTECTED] writes:
Michael Fuhr wrote:
Thanks -- I overlooked that in src/test/regress/README.
We should probably generalise that section of the README a bit. People
might skip over it thinking this isn't a locale difference.
I'm wondering why we still have a README
Michael Fuhr [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hmm ... if it's *not* a version thing then I really do want to know
what's causing it. Anyone have an idea why this machine is saying
'\u80' where everyone else's python says u'\x80' ?
The regression tests that are failing are from the
On Sat, Jul 23, 2005 at 07:58:21PM -0400, Andrew Dunstan wrote:
Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
I don't think it's a version issue; cuckoo is at 2.4, platypus used to
be at 2.3 but I upgraded it to 2.4 to see if that was the issue, but
platypus kept working.
Hmm ...
On Tue, Jul 19, 2005 at 01:54:00PM -0600, Michael Fuhr wrote:
On Tue, Jul 19, 2005 at 02:48:52PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
I don't think it's a version issue; cuckoo is at 2.4, platypus used to
be at 2.3 but I upgraded it to 2.4 to see if that was the
On Tue, Jul 19, 2005 at 03:11:35PM -0500, Jim C. Nasby wrote:
On Tue, Jul 19, 2005 at 01:54:00PM -0600, Michael Fuhr wrote:
Does this machine have ldd or the equivalent? If so, can you compare
ldd /path/to/python and ldd /path/to/plpython.so?
Oddly, no, it doesn't seem to have ldd. And
Jim C. Nasby wrote:
And the buildfarm script seems
to clean everything up even in the pgsqlkeep directories; or at least I
couldn't find a plpython.so laying around.
Nothing should be removed. If you are using the experimental code I
recently gave you all bets are off, but under normal
On Tue, Jul 19, 2005 at 02:42:07PM -0600, Michael Fuhr wrote:
On Tue, Jul 19, 2005 at 03:11:35PM -0500, Jim C. Nasby wrote:
On Tue, Jul 19, 2005 at 01:54:00PM -0600, Michael Fuhr wrote:
Does this machine have ldd or the equivalent? If so, can you compare
ldd /path/to/python and ldd
On Tue, Jul 19, 2005 at 04:51:03PM -0500, Jim C. Nasby wrote:
Can you search the system for all files named libpython* and post
what you find?
[EMAIL PROTECTED]:42]~:11%locate libpython
/Applications/NeoOfficeJ.app/Contents/MacOS/libpython.dylib
On Tue, Jul 19, 2005 at 06:06:00PM -0500, Jim C. Nasby wrote:
[EMAIL
PROTECTED]:00]~/buildfarm/HEAD/pgsqlkeep.1121809875/src/pl/plpython:41%otool
-L libplpython.0.0.so
libplpython.0.0.so:
/System/Library/Frameworks/Python.framework/Versions/2.3/Python
(compatibility version
14 matches
Mail list logo
