> > >> The problem with this is that it creates an ABI breakage.
> >
> > > Is that actually a problem given that apps should link to the driver
> > > manager (which can dynamically load any version of any driver), not
> > > directly to the driver itself?
> >
> > Hm, good point. So the question then becomes whether the
> > driver manager
> > is expecting this parameter to be int-sized or pointer-sized.
>
> It /should/ be expecting SQLPOINTER (well, SQLSetConnectAttr expects
> SQLPOINTER, and SQLSetConnectOption maps directly to it according to the
> spec -
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/ht
> m/odbcsqlsetconnectattr.asp)
PGAPI_SetConnectOption is private hidden function. It's called from
SQL* functions which are public - exported (I'm sorry I'm using terms
from OOP but I don't know the right one). No one who follows ODBC
specification may use functions which doesn't begin with SQL.
The parameter for SQLSetConnectAttr (from which is
PGAPI_SetConnectOption mainly called) is SQLPOINTER.
I check whole code to calling PGAPI_SetConnectOption so there could be
no problem with it.
> > I took a quick look at the unixODBC sources (2.0.4 which is
> > what I have
> > handy, I know it's a bit old) and got completely confused: I see the
> > parameter declared as SQLUINTEGER in some places and UDWORD in others.
> > Anyone know that code base well enough to be certain which place is
> > definitive?
>
> Not I. Our code seems to be a mess of types as well :-(
There is more types in psqlodbc like UInt4, int, ...
I think the best API manual is on MS web (Dave's link above). unixODBC
follows it.
Regards,
Luf
