Am Freitag, 29. Juli 2005 16:34 schrieb Tom Lane:
Yeah. I desisted from deleting it after I noticed that there are
provisions for re-generating it over in the doc/src/sgml Makefile.
However, I'm now wondering why it's not handled exactly like INSTALL
--- ie, don't keep it in CVS, but
Am Sonntag, 24. Juli 2005 17:53 schrieb Tom Lane:
I'm wondering why we still have a README there at all --- it's entirely
superseded by the SGML documentation.
http://developer.postgresql.org/docs/postgres/regress-evaluation.html
I think we kept it there so people can read it during the
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Sonntag, 24. Juli 2005 17:53 schrieb Tom Lane:
I'm wondering why we still have a README there at all --- it's entirely
superseded by the SGML documentation.
http://developer.postgresql.org/docs/postgres/regress-evaluation.html
I think we kept
On Sun, Jul 24, 2005 at 10:55:08AM -0400, Tom Lane wrote:
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?
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
Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Tue, Jul 19, 2005 at 10:03:39AM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Attached is a plpython_error_1.out file that will fix cuckoo.
What is the reason for the difference in the error
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 05:47:37PM -0600, Michael Fuhr wrote:
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:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Tue, Jul 19, 2005 at 10:03:39AM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Attached is a plpython_error_1.out file that will fix cuckoo.
What is the reason for the difference in the error message spelling
in the first place? Is
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 issue, but
platypus kept working.
Hmm ... if it's *not* a
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
22 matches
Mail list logo
