Обсуждение: compiler warnings in ODBC
Can someone look at this compiler warning I am seeing in ODBC: --------------------------------------------------------------------------- gcc -O2 -pipe -m486 -Wall -Wmissing-prototypes -Wmissing-declarations -g -Wall - O1 -Wmissing-prototypes -Wmissing-declarations -fpic -I. -I../../../src/include -I/usr/local/include/readline -I/usr/contrib/include -DODBCINSTDIR='"/usr/local/ pgsql/etc"' -c -o info.o info.c info.c: In function `PGAPI_ForeignKeys': info.c:2901: warning: `pkey_text' might be used uninitialized in this function info.c:2903: warning: `fkey_text' might be used uninitialized in this function info.c:2905: warning: `pkt_text' might be used uninitialized in this function info.c:2907: warning: `fkt_text' might be used uninitialized in this function -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian wrote: > > > Bruce Momjian wrote: > > > > > > Can someone look at this compiler warning I am seeing in ODBC: > > > > > > > > > > > > BTW why are people configuring with --enable-odbc ? > > I enable all I can so I can check more of the code during a compile. > ISTM neither you nor Philip Warner would use the driver in reality. I'm suspicious if --enable-odbc has a meaning without the environment. We could have 3 kind of ODBC drivers under unix now. 1) stand-alone driver made with --enable-odbc. 2) iODBC driver made with --with-iodbc. 3) unixODBC driver made with --with-unixODBC. Because they are exclusive, it seems to have little meaning to make 1) in advance. In addition it seems misleading if people would regard 1) as the standard PG driver. regards, Hiroshi Inoue
Bruce Momjian wrote: > > Can someone look at this compiler warning I am seeing in ODBC: > > --------------------------------------------------------------------------- > > gcc -O2 -pipe -m486 -Wall -Wmissing-prototypes -Wmissing-declarations -g -Wall - > O1 -Wmissing-prototypes -Wmissing-declarations -fpic -I. -I../../../src/include > -I/usr/local/include/readline -I/usr/contrib/include -DODBCINSTDIR='"/usr/local/ > pgsql/etc"' -c -o info.o info.c > info.c: In function `PGAPI_ForeignKeys': > info.c:2901: warning: `pkey_text' might be used uninitialized in this function > info.c:2903: warning: `fkey_text' might be used uninitialized in this function > info.c:2905: warning: `pkt_text' might be used uninitialized in this function > info.c:2907: warning: `fkt_text' might be used uninitialized in this function > Hmm you seem to be compiling it with multibyte enabled. OK I would suppress the warnings. BTW why are people configuring with --enable-odbc ? regards, Hiroshi Inoue
> Bruce Momjian wrote: > > > > Can someone look at this compiler warning I am seeing in ODBC: > > > > --------------------------------------------------------------------------- > > > > gcc -O2 -pipe -m486 -Wall -Wmissing-prototypes -Wmissing-declarations -g -Wall - > > O1 -Wmissing-prototypes -Wmissing-declarations -fpic -I. -I../../../src/include > > -I/usr/local/include/readline -I/usr/contrib/include -DODBCINSTDIR='"/usr/local/ > > pgsql/etc"' -c -o info.o info.c > > info.c: In function `PGAPI_ForeignKeys': > > info.c:2901: warning: `pkey_text' might be used uninitialized in this function > > info.c:2903: warning: `fkey_text' might be used uninitialized in this function > > info.c:2905: warning: `pkt_text' might be used uninitialized in this function > > info.c:2907: warning: `fkt_text' might be used uninitialized in this function > > > > Hmm you seem to be compiling it with multibyte enabled. > OK I would suppress the warnings. Thanks. > BTW why are people configuring with --enable-odbc ? I enable all I can so I can check more of the code during a compile. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> ISTM neither you nor Philip Warner would use the driver > in reality. I'm suspicious if --enable-odbc has a meaning > without the environment. We could have 3 kind of ODBC > drivers under unix now. > 1) stand-alone driver made with --enable-odbc. > 2) iODBC driver made with --with-iodbc. > 3) unixODBC driver made with --with-unixODBC. > > Because they are exclusive, it seems to have little meaning > to make 1) in advance. In addition it seems misleading if > people would regard 1) as the standard PG driver. I never run the code, just compile it. In fact, I don't use PostgreSQL at all except for PostgreSQL development, and never have. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Can someone look at this compiler warning I am seeing in ODBC:
Fixed.
regards, tom lane
Hiroshi Inoue writes: > ISTM neither you nor Philip Warner would use the driver > in reality. I'm suspicious if --enable-odbc has a meaning > without the environment. We could have 3 kind of ODBC > drivers under unix now. > 1) stand-alone driver made with --enable-odbc. > 2) iODBC driver made with --with-iodbc. > 3) unixODBC driver made with --with-unixODBC. > > Because they are exclusive, it seems to have little meaning > to make 1) in advance. In addition it seems misleading if > people would regard 1) as the standard PG driver. It probably doesn't make the greatest possible sense, but it's backward compatible and consistent with typical configure options. Btw., to get the iODBC driver, you need both options --with-iodbc and --enable-odbc. If you only use the former, you get nothing at all. Again, this could conceivably be done differently. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter Eisentraut wrote: > > Hiroshi Inoue writes: > > > ISTM neither you nor Philip Warner would use the driver > > in reality. I'm suspicious if --enable-odbc has a meaning > > without the environment. We could have 3 kind of ODBC > > drivers under unix now. > > 1) stand-alone driver made with --enable-odbc. > > 2) iODBC driver made with --with-iodbc. > > 3) unixODBC driver made with --with-unixODBC. > > > > Because they are exclusive, it seems to have little meaning > > to make 1) in advance. In addition it seems misleading if > > people would regard 1) as the standard PG driver. > > It probably doesn't make the greatest possible sense, but it's backward > compatible and consistent with typical configure options. > > Btw., to get the iODBC driver, you need both options --with-iodbc and > --enable-odbc. If you only use the former, you get nothing at all. > Again, this could conceivably be done differently. --enable-odbc=standalone --enable-odbc=iODBC --enable-odbc=unixODBC could be the logical way to do it ? ---------------- Hannu
> --enable-odbc=standalone > --enable-odbc=iODBC > --enable-odbc=unixODBC > > could be the logical way to do it ? > This seems to make sense to me. Also; it would be nice if someone would write a couple of m4 macros for detecting defaults (i.e. Is unixODBC being used on the system? Is iODBC being used on the system?). -- Peter Harvey CodeByDesign - http://www.codebydesign.com DataArchitect - http://www.codebydesign.com/DataArchitect
Peter Eisentraut wrote: > > Hiroshi Inoue writes: > > > ISTM neither you nor Philip Warner would use the driver > > in reality. I'm suspicious if --enable-odbc has a meaning > > without the environment. We could have 3 kind of ODBC > > drivers under unix now. > > 1) stand-alone driver made with --enable-odbc. > > 2) iODBC driver made with --with-iodbc. > > 3) unixODBC driver made with --with-unixODBC. > > > > Because they are exclusive, it seems to have little meaning > > to make 1) in advance. In addition it seems misleading if > > people would regard 1) as the standard PG driver. > > It probably doesn't make the greatest possible sense, but it's backward > compatible and consistent with typical configure options. There seems to be pretty many users who only compile the driver but how many real users are there ? The driver hasn't been easy to use with iODBC and unfortunately I remember no response from PG users to the postings on ML like .. I can't connect to .. IMHO users shouldn't specify the option --enable-odbc aimlessly and should choose either iODBC, unixODBC or stand-alone consciouly. > > Btw., to get the iODBC driver, you need both options --with-iodbc and > --enable-odbc. If you only use the former, you get nothing at all. Really ? I see the following in ./configure. if test "$with_unixodbc" = yes || test "$with_iodbc" = yes; then enable_odbc=yes fi regards, Hiroshi Inoue
> There seems to be pretty many users who only compile > the driver but how many real users are there ? > The driver hasn't been easy to use with iODBC and > unfortunately I remember no response from PG users > to the postings on ML like .. I can't connect to .. > IMHO users shouldn't specify the option --enable-odbc > aimlessly and should choose either iODBC, unixODBC > or stand-alone consciouly. The version I use works great with unixODBC. Also; I would imagine that *most* people using ODBC would want to use a Driver Manager. -- Peter Harvey CodeByDesign - http://www.codebydesign.com DataArchitect - http://www.codebydesign.com/DataArchitect
Hannu Krosing writes: > > Btw., to get the iODBC driver, you need both options --with-iodbc and > > --enable-odbc. If you only use the former, you get nothing at all. > > Again, this could conceivably be done differently. > > --enable-odbc=standalone > --enable-odbc=iODBC > --enable-odbc=unixODBC > > could be the logical way to do it ? Logical maybe, but not consistent with typical configure options. If you want to build your package while using some other package for it, then the option is --with-package. I could imagine making --enable-odbc optional in that case, though. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter Harvey writes: > Also; it would be nice if someone would write a couple of m4 macros > for detecting defaults (i.e. Is unixODBC being used on the system? Is > iODBC being used on the system?). This is sort of my long-term idea, i.e., just use "the" ODBC driver that's available. However, I'm not sure if it's entirely appropriate to do that, for a number of reasons, one of which is that unixODBC and iODBC aren't pretending to be compatible, another is that if this were the way to go then we wouldn't really have a place for the standalone driver. For now, I think giving people the explicit choice is a good way to see where this is going at all. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter Eisentraut wrote: > > Hannu Krosing writes: > > > > Btw., to get the iODBC driver, you need both options --with-iodbc and > > > --enable-odbc. If you only use the former, you get nothing at all. > > > Again, this could conceivably be done differently. > > > > --enable-odbc=standalone > > --enable-odbc=iODBC > > --enable-odbc=unixODBC > > > > could be the logical way to do it ? > > Logical maybe, but not consistent with typical configure options. If you > want to build your package while using some other package for it, then the > option is --with-package. I could imagine making --enable-odbc optional > in that case, though. > My understanding was that different ODBC variants were mutually exclusive while other packages are not. Thus a separate option. it could be also --with-odbc=xxxODBC or --enable-odbc=xxxODBC ------------ Hannu
On Monday 05 November 2001 12:05, Peter Eisentraut wrote: > Peter Harvey writes: > > Also; it would be nice if someone would write a couple of m4 macros > > for detecting defaults (i.e. Is unixODBC being used on the system? Is > > iODBC being used on the system?). > > This is sort of my long-term idea, i.e., just use "the" ODBC driver that's > available. However, I'm not sure if it's entirely appropriate to do that, > for a number of reasons, one of which is that unixODBC and iODBC aren't > pretending to be compatible, another is that if this were the way to go > then we wouldn't really have a place for the standalone driver. For now, > I think giving people the explicit choice is a good way to see where this > is going at all. unixODBC and iODBC have actually been working towards the same goal. The specification is clear enough. The difference is that they have had different levels of resources and different priorities. Having said that; I am just happy to see people taking the time to work these issues out :) -- Peter Harvey CodeByDesign - http://www.codebydesign.com DataArchitect - http://www.codebydesign.com/DataArchitect