Thread: PL/Python warnings in CVS HEAD
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. -Neil
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
Attachment
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
Attachment
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
Attachment
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
Attachment
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. +