Hi Magnus and all.
From: "Magnus Hagander"
Hiroshi Saito wrote:
Ok. So there are actually two ways to go about it:
1) Discontinue support for MSVC6 and require MSVC8
2) Change it so that MSVC6 can still build libpq, just not with SSPI
support. This can be done by conditionally enabling ENABLE_SSPI, so it's
not that hard.
The question is, if we go with option 2, is it something that anybody
actually will *use*?
I desire 1 as formal. However, It contains VC7.1 and VC8.
Moreover, libpq.dll can be used by the module of VC6.
Is there any actual reason to keep VC7.1 support?
It is still used and has sufficient function. Then, Inoue-san is developing in the
environment.:-)
The project file of VC7.1 differs from VC8 a little. However, nmake.exe absorbs
it.
for the reasons, we are maintaining win32.mak. but, project file offers the
minimum function
in simple. MSDTC is a reason for being somewhat more complicated than standard
compile.
VC6 has one reason only to exist, and that's that it doesn't carry the
dependencies that VC8 does. But VC7 does (different ones, but just as many).
So if we're dropping support for VC6, my suggestion is that we drop
support for *any* win32 compiler other than VC8 and MingW gcc.
By the PostgreSQL main part, I think that you may limit with support of VC7.1,
VC8,
and MinGW (gcc) by SSPI to which you are working. Although our psqlODBC uses
libpq.dll,
a wired protocol realizes it. Although I have not tested SSPI yet, However, I
am checking
normal of compile.
If I'm not mistaken, one of the original reasons we kept the win32.mak
method around after we had the "complete msvc build" was for the ODBC
folks. Are you saying that the ODBC guys are now happy with a MSVC8
build?
Yes, They are offered as comfortable environment. pgAdmin and that's
right.!:-)
However, psqlODBC also contains legacy VC6. They will clear a problem by
the cause libpq.dll wire. Even if it may be adjusted from now on. probably.
I'm sorry, I don't fully understand you here. Which one of the following
three is it (or is it something else altogether)?
1) Does ODBC *require* a MSVC6 build libpq.dll?
2) Can ODBC work with MVC8 built libpq, but ODBC is built with MSVC6?
3) Can ODBC be built with MSVC8 and use the MSVC8 built libpq?
It would be unfortunate if ODBC has to ship with a different set of
dependencies than libpq, but as long as they build with either VC6 or
VC8 that shouldn't happen.
1 above would be really bad, but I'm 99% sure that's not so, since I've
actually tested SSPI auth with such a libpq.
IMO, the best option would be 3, but I don't know enough about the ODBC
driver to comment on there. I'll CC this to the odbc list so we can get
more input from other people there.
I'm sure that 3 is sufficient. I will begin the preparation.
Of course, if there is a problem, though it will be corrected.
P.S) The present situation.(as for psqlODBC)
Compile (VC6, VC8) does not look at a problem by CVS-HEAD of pgsql.!!
But, The test is not completed....I apologize for the overdue work...
Regards,
Hiroshi Saito
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
