Re: [PATCHES] cast pid_t to int when using *printf
On Fri, 2004-09-24 at 16:51, Oliver Jowett wrote: > gcc (3.2.3 on Solaris 9) warns about a couple of places where a pid_t is > formatted with %d by a printf-family function. For curiosity's sake, what formatting escape does gcc prefer? -Neil ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] cast pid_t to int when using *printf
Neil Conway wrote: On Fri, 2004-09-24 at 16:51, Oliver Jowett wrote: gcc (3.2.3 on Solaris 9) warns about a couple of places where a pid_t is formatted with %d by a printf-family function. For curiosity's sake, what formatting escape does gcc prefer? I don't think there is an escape for pid_t, you always have to cast it. -O ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] psql: rollback only last query on error
> "Michael Paesold" <[EMAIL PROTECTED]> writes: > > Alvaro Herrera wrote: > >> One potential problem I see with the patch is that it opens lots of > >> savepoints but does not release any. > > > Well, given that EXCEPTION blocks in Pl/pgSQL and the like also never > > release savepoints > > That statement is flat wrong. I have to say that I am sorry that I misunderstood that. Regards, Michael Paesold -- +++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++ Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] cast pid_t to int when using *printf
Am Freitag, 24. September 2004 09:34 schrieb Oliver Jowett: > Neil Conway wrote: > > On Fri, 2004-09-24 at 16:51, Oliver Jowett wrote: > >>gcc (3.2.3 on Solaris 9) warns about a couple of places where a pid_t is > >>formatted with %d by a printf-family function. > > > > For curiosity's sake, what formatting escape does gcc prefer? > > I don't think there is an escape for pid_t, you always have to cast it. I think what he was asking is this: Since pid_t has to be a signed integer type, but gcc does not accept %d for it, then it could be that pid_t is wider than an int, so casting it to int would potentially lose information. (Btw., the Windows port defines pid_t as unsigned long; that's surely wrong.) -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] cast pid_t to int when using *printf
> (Btw., the Windows port defines pid_t as unsigned long; > that's surely wrong.) In what way is that wrong? A PID on Windows is a DWORD, which is an unsigned long. Or am I missing something (probably..)? //Magnus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] cast pid_t to int when using *printf
Am Freitag, 24. September 2004 11:06 schrieb Magnus Hagander: > > (Btw., the Windows port defines pid_t as unsigned long; > > that's surely wrong.) > > In what way is that wrong? A PID on Windows is a DWORD, which is an > unsigned long. Or am I missing something (probably..)? The mingw header files define pid_t as int, so we shouldn't redefine it in the first place. The rest of the POSIX world also assumes that pid_t is signed, so you might break a bunch of interfaces if it's not. Note that this is independent of the fact that the actual process identifiers are all positive, both on Windows and on Unix systems. (Tertiary note: Never #define one type to another, always use typedef.) -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] cast pid_t to int when using *printf
Peter Eisentraut wrote: Am Freitag, 24. September 2004 09:34 schrieb Oliver Jowett: Neil Conway wrote: On Fri, 2004-09-24 at 16:51, Oliver Jowett wrote: gcc (3.2.3 on Solaris 9) warns about a couple of places where a pid_t is formatted with %d by a printf-family function. For curiosity's sake, what formatting escape does gcc prefer? I don't think there is an escape for pid_t, you always have to cast it. I think what he was asking is this: Since pid_t has to be a signed integer type, but gcc does not accept %d for it, then it could be that pid_t is wider than an int, so casting it to int would potentially lose information. pid_t on the Solaris/sparc system is a long (but both int and long are 32 bits). Some experimentation shows that gcc is happy with a %ld format specifier. But compiling the same code on a Linux/x86 system makes gcc complain when applying %ld to pid_t, so we will need a cast there either way. I notice that elog.c casts MyProcPid to long and uses %ld. Amusingly, MyProcPid is explicitly an int.. -O ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] cast pid_t to int when using *printf
On Fri, 2004-09-24 at 20:31, Oliver Jowett wrote: > pid_t on the Solaris/sparc system is a long (but both int and long are > 32 bits). Some experimentation shows that gcc is happy with a %ld format > specifier. But compiling the same code on a Linux/x86 system makes gcc > complain when applying %ld to pid_t, so we will need a cast there either > way. I guess it would be safest to use %ld and cast pid_t to long. Of course, this seems a little paranoid -- is there actually a system with sizeof(pid_t) != 4? -Neil ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] cast pid_t to int when using *printf
Neil Conway <[EMAIL PROTECTED]> writes: > I guess it would be safest to use %ld and cast pid_t to long. Of course, > this seems a little paranoid -- is there actually a system with > sizeof(pid_t) != 4? Traditionally PIDs fit in 16 bits, let alone 32. I'd recommend that we standardize on casting pid_t to int for printing purposes; I think that's what's being done in more places than not. Also, as you note, we are using int variables to hold PIDs in many places --- I don't think it's worth running around and changing those either. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] Code/comment cleanups now that odbc is gone.
Here ae some code/comment cleanups now that the odbc interface is no longer part of the main distribution. Kris JurkaIndex: src/backend/libpq/md5.c === RCS file: /projects/cvsroot/pgsql-server/src/backend/libpq/md5.c,v retrieving revision 1.25 diff -c -r1.25 md5.c *** src/backend/libpq/md5.c 29 Aug 2004 04:12:32 - 1.25 --- src/backend/libpq/md5.c 24 Sep 2004 16:44:03 - *** *** 18,32 */ ! /* ! *NOTE: ! * ! *There are two copies of this file, one in backend/libpq and another ! *in interfaces/odbc. They should be identical. This is done so ODBC ! *can be compiled stand-alone. ! */ ! ! #if ! defined(MD5_ODBC) && ! defined(FRONTEND) #include "postgres.h" #include "libpq/crypt.h" #endif --- 18,24 */ ! #if ! defined(FRONTEND) #include "postgres.h" #include "libpq/crypt.h" #endif *** *** 34,51 #ifdef FRONTEND #include "postgres_fe.h" #include "libpq/crypt.h" - #endif /* FRONTEND */ - #ifdef MD5_ODBC - #include "md5.h" - #endif - - #ifdef FRONTEND #undef palloc #define palloc malloc #undef pfree #define pfree free ! #endif /* --- 26,37 #ifdef FRONTEND #include "postgres_fe.h" #include "libpq/crypt.h" #undef palloc #define palloc malloc #undef pfree #define pfree free ! #endif /* FRONTEND */ /* Index: src/include/c.h === RCS file: /projects/cvsroot/pgsql-server/src/include/c.h,v retrieving revision 1.173 diff -c -r1.173 c.h *** src/include/c.h 23 Sep 2004 13:16:02 - 1.173 --- src/include/c.h 24 Sep 2004 16:44:03 - *** *** 231,237 *used for numerical computations and the *frontend/backend protocol. */ - /* Also defined in interfaces/odbc/md5.h */ #ifndef HAVE_UINT8 typedef unsigned char uint8; /* == 8 bits */ typedef unsigned short uint16;/* == 16 bits */ --- 231,236 Index: src/include/libpq/crypt.h === RCS file: /projects/cvsroot/pgsql-server/src/include/libpq/crypt.h,v retrieving revision 1.28 diff -c -r1.28 crypt.h *** src/include/libpq/crypt.h 29 Aug 2004 04:13:07 - 1.28 --- src/include/libpq/crypt.h 24 Sep 2004 16:44:03 - *** *** 15,21 #include "libpq/libpq-be.h" - /* Also defined in interfaces/odbc/md5.h */ #define MD5_PASSWD_LEN35 #define isMD5(passwd) (strncmp((passwd),"md5",3) == 0 && \ --- 15,20 *** *** 27,33 extern bool md5_hash(const void *buff, size_t len, char *hexsum); extern bool CheckMD5Pwd(char *passwd, char *storedpwd, char *seed); - /* Also defined in interfaces/odbc/md5.h */ extern bool EncryptMD5(const char *passwd, const char *salt, size_t salt_len, char *buf); --- 26,31 ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] libpq verinfo patch
Here is a patch that adds the version info from libpq.rc to the DLL build in mingw. The MSVC build already did this, but it was not linked into the mingw one. This is not the same as the versioninfo patch that's in the queue. Please apply this one before beta-3 if at all possible. //Magnus libpqver.patch Description: libpqver.patch ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] plpython win32
Hi! This patch attempts to fix the build of plpython on win32. Needs autoconf of course - don't have mine working on win32, so that part hasn't been 100% tested. My tests involved #:ing out all the code that would be included by that rule, and that makes it work, so I think we're safe //Magnus plpython_win32.patch Description: plpython_win32.patch ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] plpython win32
"Magnus Hagander" <[EMAIL PROTECTED]> writes: > This patch attempts to fix the build of plpython on win32. How is python_includespec going to get set if we don't run the autoconf test that finds it out? I'm quite unthrilled with hardwiring the python version number, as well. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] plpython win32
>> This patch attempts to fix the build of plpython on win32. > >How is python_includespec going to get set if we don't run the >autoconf test that finds it out? I'm quite unthrilled with hardwiring >the python version number, as well. We run the first part of the autoconf test. The one that sets python_includespec. (PGAC_PATH_PYTHON) We just skip the parts that tries to read the Makefile. If there is a good way, that subst command could/should be changed to just strip the last part of the directory. PGAC_PATH_PYTHON appends te python version, which is not correct on win32. //Magnus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[PATCHES] Translation updates for 8.0: libpq-ru, pg_controldata-ru
Hello, Attached are translation fixes for libpq and pg_controldata to bring them up to date again. Thanks, -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! libpq-ru.po.gz Description: GNU Zip compressed data pg_controldata-ru.po.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] plpython win32
Magnus Hagander wrote: > This patch attempts to fix the build of plpython on win32. Needs > autoconf of course - don't have mine working on win32, so that part > hasn't been 100% tested. My tests involved #:ing out all the code > that would be included by that rule, and that makes it work, so I > think we're safe Please do not use PORTNAME in external macros. I like to think that one can take these macros and put them in some other project without requiring the prior setup that the PostgreSQL configure.in does. Instead, use AC_REQUIRE([AC_CANONICAL_HOST]) and resolve the issue using $host_os. Also, add some comments to the magic you add in the makefiles. The hardcoded Python version number will of course not stand the test of time. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] plpython win32
Magnus Hagander wrote: > If there is a good way, that subst command could/should be changed to > just strip the last part of the directory. PGAC_PATH_PYTHON appends > te python version, which is not correct on win32. I'm curious to know how the code AC_PATH_PROG(PYTHON, python) "appends the python version". -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] plpython win32
>> If there is a good way, that subst command could/should be changed to
>> just strip the last part of the directory. PGAC_PATH_PYTHON appends
>> te python version, which is not correct on win32.
>
>I'm curious to know how the code
>
>AC_PATH_PROG(PYTHON, python)
>
>"appends the python version".
No. Not that one. PGAC_PATH_PYTHON. That is a different line. It's
defined in config/python.m4. The line is:
python_includespec="-I${python_prefix}/include/python${python_version}"
//Magnus
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] plpython win32
Magnus Hagander wrote:
> No. Not that one. PGAC_PATH_PYTHON. That is a different line. It's
> defined in config/python.m4. The line is:
>
> python_includespec="-I${python_prefix}/include/python${python_version
>}"
Are we reading the same code?
# PGAC_PATH_PYTHON
#
# Look for Python and set the output variable 'PYTHON'
# to 'python' if found, empty otherwise.
AC_DEFUN([PGAC_PATH_PYTHON],
[AC_PATH_PROG(PYTHON, python)
if test x"$PYTHON" = x""; then
AC_MSG_ERROR([Python not found])
fi
])
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] plpython win32
>> No. Not that one. PGAC_PATH_PYTHON. That is a different line. It's
>> defined in config/python.m4. The line is:
>>
>> python_includespec="-I${python_prefix}/include/python${python_version
>>}"
>
>Are we reading the same code?
>
># PGAC_PATH_PYTHON
>#
># Look for Python and set the output variable 'PYTHON'
># to 'python' if found, empty otherwise.
>AC_DEFUN([PGAC_PATH_PYTHON],
>[AC_PATH_PROG(PYTHON, python)
>if test x"$PYTHON" = x""; then
> AC_MSG_ERROR([Python not found])
>fi
>])
Not quite. Further down in that same file. Seems I mean
PGAC_CHECK_PYTHON_DIRS :-) Not used to these files... I guess that means
that I'm off on the wrong path. :-(
Anyway. The issue is that there is no Makefile in $python_configdir.
That's the part that we need to get rid of. Any pointers? Some kind of
if in python.m4 then probably?
//Magnus
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] plpython win32
"Magnus Hagander" <[EMAIL PROTECTED]> writes: > We run the first part of the autoconf test. The one that sets > python_includespec. (PGAC_PATH_PYTHON) We just skip the parts that tries > to read the Makefile. It would be better to put an "if" in the PGAC_CHECK_PYTHON_EMBED_SETUP macro, and have it use some other technique for obtaining the info it needs when on Windows. If they don't have a Makefile, one would hope they have some other kind of file that has the needed info. Or doesn't Python support embedding on Windows? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
