compiler warnings in ODBC

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, Pennsylvania 19026

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

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, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Can someone look at this compiler warning I am seeing in ODBC:

Fixed.

regards, tom lane

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

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

--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

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

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

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