Обсуждение: libpq and libpgtcl in Windows
Hi all I made dll's(libpq.dll,libpgtcl.dll) only for pgaccess. It is a temporary solution for quick fix and the solution for general use is necessary. I made libpgtcl.dll ignoring NOTIFY functionality(not used in pgaccess). Sorry,I'm not a Tcl expert and can't provide proper code for NOTIFY functionality in Windows. Another problem exists between libpq and libpgtcl in Windows. Libpgtcl references global data pgresStatus[] in libpq when using pg_result -status command. But in Windows libpgtcl doesn't reference pgresStatus[] in the same way as UNIX and pg_result -status returns improper values. Any ideas ? In my temporary solution for pgaccess,I used a function interface between libpq and libpgtcl instead of global data. Thanks Hiroshi Inoue Inoue@tpf.co.jp
Hi all. I have changed the subject from "libpq and libpgtcl in Windows". My main point is The treatment of pgresStatus[] in libpq must be changed ? In case of Windows,global data interface between dll's is different from UNIX. If fact,libpgtcl references global data pgresStatus[] in libpq and pg_result -status command does not work properly for Windows. I think it is preferable to use function interfaces than gobal data references. Any ideas ? Thanks Hiroshi Inoue Inoue@tpf.co.jp PS. I accepted a lot of mails about libpq and libpgtcl. Seems many people thought I am good at libpq,Tcl etc. But my work is only the compilation of libpq and libpgtcl. LIBPQ for WIN32 is the work of Magnus Hagander. I changed libpgtcl and libpq just a little for pgaccess. The dll's I provieded are only for pgaccess not for general use.
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > The treatment of pgresStatus[] in libpq must be changed ? > In case of Windows,global data interface between dll's is > different from UNIX. > If fact,libpgtcl references global data pgresStatus[] in libpq > and pg_result -status command does not work properly for > Windows. I don't think we can really take pgresStatus[] out of libpq's API, since that would break existing applications for no good reason. But it seems reasonable to add a corresponding function call, say const char * PQresStatus (ExecStatusType status); and change libpgtcl to use that instead. We could even deprecate use of the global array with an eye to removing it someday ... not very soon though. Anyone have an objection, or a different opinion about what the function should be named? regards, tom lane
Hello all. > -----Original Message----- > From: owner-pgsql-interfaces@postgreSQL.org > [mailto:owner-pgsql-interfaces@postgreSQL.org]On Behalf Of Hiroshi Inoue > Subject: [INTERFACES] The problem between libpq and libpgtcl for WIN32 > > > The treatment of pgresStatus[] in libpq must be changed ? > > In case of Windows,global data interface between dll's is > different from UNIX. > If fact,libpgtcl references global data pgresStatus[] in libpq > and pg_result -status command does not work properly for > Windows. > > I think it is preferable to use function interfaces than gobal > data references. > > Any ideas ? I solved this problem by the change in the following. ======== cut here ======== *** libpq-fe.h.dist Tue Oct 6 23:16:48 1998 --- libpq-fe.h Tue Dec 15 03:52:34 1998 *************** *** 50,56 **** --- 50,60 ---- } ExecStatusType; /* String descriptions of the ExecStatusTypes */ + #ifdef WIN32 + __declspec(dllimport) const char * const pgresStatus[]; + #else extern const char * const pgresStatus[]; + #endif /* PGconn encapsulates a connection to the backend. * The contents of this struct are not supposed to be known to applications. *** libpqdll.def.dist Tue Oct 6 23:05:02 1998 --- libpqdll.def Tue Dec 15 03:52:44 1998 *************** *** 63,68 **** lo_unlink @ 60 lo_import @ 61 lo_export @ 62 ! pgresStatus @ 63 PQmblen @ 64 PQresultErrorMessage @ 65 --- 63,68 ---- lo_unlink @ 60 lo_import @ 61 lo_export @ 62 ! pgresStatus @ 63 DATA PQmblen @ 64 PQresultErrorMessage @ 65 ======== cut here ======== "pg_result -status" operates correctly by this method. Moreover, it is thought that this method is easy because the change part is in libpq. -- Hiroki Kataoka kataoka@interwiz.koganei.tokyo.jp