PL/Python warnings in CVS HEAD

Neil Conway wrote:

FYI, I see the following warnings compiling CVS HEAD:

src/pl/plpython/plpython.c:2006: warning: initialization from
incompatible pointer type
src/pl/plpython/plpython.c:2008: warning: 'intargfunc' is deprecated
src/pl/plpython/plpython.c:2008: warning: initialization from
incompatible pointer type
src/pl/plpython/plpython.c:2009: warning: 'intargfunc' is deprecated
src/pl/plpython/plpython.c:2009: warning: initialization from
incompatible pointer type
src/pl/plpython/plpython.c:2010: warning: 'intintargfunc' is deprecated
src/pl/plpython/plpython.c:2010: warning: initialization from
incompatible pointer type
src/pl/plpython/plpython.c:2011: warning: initialization from
incompatible pointer type
src/pl/plpython/plpython.c:2012: warning: initialization from
incompatible pointer type

This is on Ubuntu fiesty, Python 2.5, gcc 4.1.2, AMD64.

There is no Ubuntu Fiesty... yet ;) you are compile -head with -head...
sounds like a snafu to begin with (yes I am being a pain on purpose.

Joshua D. Drake

-Neil

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

src/pl/plpython/plpython.c:2010: warning: 'intintargfunc' is deprecated
src/pl/plpython/plpython.c:2010: warning: initialization from
incompatible pointer type
src/pl/plpython/plpython.c:2011: warning: initialization from
incompatible pointer type
src/pl/plpython/plpython.c:2012: warning: initialization from
incompatible pointer type

This is on Ubuntu fiesty, Python 2.5, gcc 4.1.2, AMD64.

There is no Ubuntu Fiesty... yet ;) you are compile -head with -head...
sounds like a snafu to begin with (yes I am being a pain on purpose.

Ubuntu Edgy, Python 2.4, gcc 4.1.2 AMD64

jd@scratch:/media/music/jd/pgsql/src/pl/plpython$ make
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fpic
-I. -I/usr/include/python2.4 -I../../../src/include -D_GNU_SOURCE -c
-o plpython.o plpython.c
ar crs libplpython.a plpython.o
ranlib libplpython.a
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fpic
-shared -Wl,-soname,libplpython.so.0 plpython.o -L/usr/lib
-L../../../src/port -lpython2.4 -lpthread -ldl -lutil -lm
-Wl,-rpath,'/usr/lib' -o libplpython.so.0.0
rm -f libplpython.so.0
ln -s libplpython.so.0.0 libplpython.so.0
rm -f libplpython.so
ln -s libplpython.so.0.0 libplpython.so

So looks like a python issue (I know things changed a bit in 2.5).

Joshua D. Drake

Joshua D. Drake

-Neil

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

On Sat, 2007-03-03 at 11:21 -0800, Joshua D. Drake wrote:

There is no Ubuntu Fiesty... yet ;) you are compile -head with -head...
sounds like a snafu to begin with

No, it just looks like a Python API 2.5 change to me. I'd look into it
myself, but I don't have the free cycles at the moment.

yes I am being a pain on purpose.

Well, more signal and less noise would be nice.

-Neil

On Sat, 2007-03-03 at 14:29 -0500, Neil Conway wrote:

No, it just looks like a Python API 2.5 change to me

Attached is a patch that fixes the warnings. Unfortunately, it seems
this patch won't compile against Python 2.4: the 2.5 API requires the
use of some typedef's that AFAICS were only introduced in 2.5.

Since we presumably still want to support Python < 2.5, we can either
not apply this patch and tolerate the warnings, or else we can
workaround the incompatibility with some preprecessor hackery (e.g.
supply the missing typedef's ourselves if Python doesn't provide them).

Comments?

-Neil

Neil Conway <neilc@samurai.com> writes:

No, it just looks like a Python API 2.5 change to me

Attached is a patch that fixes the warnings. Unfortunately, it seems
this patch won't compile against Python 2.4: the 2.5 API requires the
use of some typedef's that AFAICS were only introduced in 2.5.

Since we presumably still want to support Python < 2.5, we can either
not apply this patch and tolerate the warnings, or else we can
workaround the incompatibility with some preprecessor hackery (e.g.
supply the missing typedef's ourselves if Python doesn't provide them).

Sounds like #ifdef time to me --- but it seems a bit strange; wouldn't
the Python guys have taken a bit more care for compatibility of
user-supplied code? We're hardly the only people who want to support
multiple Python versions. Perhaps they provide a compatibility hack
that you didn't spot?

regards, tom lane

On Tue, 2007-03-06 at 00:18 -0500, Tom Lane wrote:

Sounds like #ifdef time to me --- but it seems a bit strange; wouldn't
the Python guys have taken a bit more care for compatibility of
user-supplied code?

Yeah, I was a bit surprised as well. I won't claim to have any
familiarity with the Python C API, though. Py_Deprecated() is simply
defined as:

/* Py_DEPRECATED(version)
* Declare a variable, type, or function deprecated.
* Usage:
* extern int old_var Py_DEPRECATED(2.3);
* typedef int T1 Py_DEPRECATED(2.4);
* extern int x() Py_DEPRECATED(2.5);
*/
#if defined(__GNUC__) && ((__GNUC__ >= 4) || \
(__GNUC__ == 3) && (__GNUC_MINOR__ >= 1))
#define Py_DEPRECATED(VERSION_UNUSED) __attribute__((__deprecated__))
#else
#define Py_DEPRECATED(VERSION_UNUSED)
#endif

Perhaps they provide a compatibility hack that you didn't spot?

Quite possibly. Anyone have any suggestions?

-Neil

On 3/6/07, Neil Conway <neilc@samurai.com> wrote:

On Tue, 2007-03-06 at 00:18 -0500, Tom Lane wrote:

Perhaps they provide a compatibility hack that you didn't spot?

Quite possibly. Anyone have any suggestions?

Python guys discuss the situation here:

http://www.python.org/dev/peps/pep-0353/

--
marko

Where are we on Python 2.5?

---------------------------------------------------------------------------

Tom Lane wrote:

Neil Conway <neilc@samurai.com> writes:

No, it just looks like a Python API 2.5 change to me

Attached is a patch that fixes the warnings. Unfortunately, it seems
this patch won't compile against Python 2.4: the 2.5 API requires the
use of some typedef's that AFAICS were only introduced in 2.5.

Since we presumably still want to support Python < 2.5, we can either
not apply this patch and tolerate the warnings, or else we can
workaround the incompatibility with some preprecessor hackery (e.g.
supply the missing typedef's ourselves if Python doesn't provide them).

Sounds like #ifdef time to me --- but it seems a bit strange; wouldn't
the Python guys have taken a bit more care for compatibility of
user-supplied code? We're hardly the only people who want to support
multiple Python versions. Perhaps they provide a compatibility hack
that you didn't spot?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On 4/3/07, Bruce Momjian <bruce@momjian.us> wrote:

Where are we on Python 2.5?

I'll look into it.

--
marko

On 4/3/07, Marko Kreen <markokr@gmail.com> wrote:

On 4/3/07, Bruce Momjian <bruce@momjian.us> wrote:

Where are we on Python 2.5?

I'll look into it.

Following patch converts plpython.c to use Python 2.5 types,
with compat ifdef for older version. This is recommended
method by PEP 353 to fix the issue.

Tested with python 2.4.3, 2.5.

--
marko

Marko Kreen escribi�:

On 4/3/07, Marko Kreen <markokr@gmail.com> wrote:

On 4/3/07, Bruce Momjian <bruce@momjian.us> wrote:

Where are we on Python 2.5?

I'll look into it.

Following patch converts plpython.c to use Python 2.5 types,
with compat ifdef for older version. This is recommended
method by PEP 353 to fix the issue.

Tested with python 2.4.3, 2.5.

No compiler warnings, regression tests pass here on Python 2.4.4.

$ uname -a
Linux perhan 2.6.18-3-amd64 #1 SMP Mon Dec 4 17:04:37 CET 2006 x86_64 GNU/Linux

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Great. Care to take on the Python boolean patch?

o Allow PL/PythonU to return boolean rather than 1/0

http://archives.postgresql.org/pgsql-patches/2007-01/msg00596.php

It requires only a few lines of code, but some testing, which you seem
to have available.

---------------------------------------------------------------------------

Marko Kreen wrote:

On 4/3/07, Marko Kreen <markokr@gmail.com> wrote:

On 4/3/07, Bruce Momjian <bruce@momjian.us> wrote:

Where are we on Python 2.5?

I'll look into it.

Following patch converts plpython.c to use Python 2.5 types,
with compat ifdef for older version. This is recommended
method by PEP 353 to fix the issue.

Tested with python 2.4.3, 2.5.

--
marko

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Patch applied. Thanks.

---------------------------------------------------------------------------

Marko Kreen wrote:

On 4/3/07, Marko Kreen <markokr@gmail.com> wrote:

On 4/3/07, Bruce Momjian <bruce@momjian.us> wrote:

Where are we on Python 2.5?

I'll look into it.

Following patch converts plpython.c to use Python 2.5 types,
with compat ifdef for older version. This is recommended
method by PEP 353 to fix the issue.

Tested with python 2.4.3, 2.5.

--
marko

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On 4/3/07, Bruce Momjian <bruce@momjian.us> wrote:

Great. Care to take on the Python boolean patch?

o Allow PL/PythonU to return boolean rather than 1/0

http://archives.postgresql.org/pgsql-patches/2007-01/msg00596.php

It requires only a few lines of code, but some testing, which you seem
to have available.

Ok.

--
marko

On 4/3/07, Marko Kreen <markokr@gmail.com> wrote:

On 4/3/07, Bruce Momjian <bruce@momjian.us> wrote:

Great. Care to take on the Python boolean patch?

o Allow PL/PythonU to return boolean rather than 1/0

I think this should be also solved with backwards-compat ifdef.

Tested with python 2.2, 2.3, 2.4, 2.5.

--
marko

Great, patch applied and TODO item removed.

---------------------------------------------------------------------------

Marko Kreen wrote:

On 4/3/07, Marko Kreen <markokr@gmail.com> wrote:

On 4/3/07, Bruce Momjian <bruce@momjian.us> wrote:

Great. Care to take on the Python boolean patch?

o Allow PL/PythonU to return boolean rather than 1/0

I think this should be also solved with backwards-compat ifdef.

Tested with python 2.2, 2.3, 2.4, 2.5.

--
marko

[ Attachment, skipping... ]

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On 4/3/07, Bruce Momjian <bruce@momjian.us> wrote:

Great, patch applied and TODO item removed.

If you are already patching, please apply the following patch also.

It removes last remaining casts inside struct definitions.
Such usage is bad practice, as it hides problems from compiler.

Reason for the cast is popular practice in some circles
to define functions as foo(MyObj *) instead of foo(PyObject *)
thus avoiding a local variable inside functions and make
direct calling easier. As pl/python does not use such style,
the casts were unnecessary from the start.

--
marko

Patch applied. Thanks.

---------------------------------------------------------------------------

Marko Kreen wrote:

On 4/3/07, Bruce Momjian <bruce@momjian.us> wrote:

Great, patch applied and TODO item removed.

If you are already patching, please apply the following patch also.

It removes last remaining casts inside struct definitions.
Such usage is bad practice, as it hides problems from compiler.

Reason for the cast is popular practice in some circles
to define functions as foo(MyObj *) instead of foo(PyObject *)
thus avoiding a local variable inside functions and make
direct calling easier. As pl/python does not use such style,
the casts were unnecessary from the start.

--
marko

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +