Обсуждение: 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