Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6])
	by hub.org (8.9.1/8.9.1) with ESMTP id UAA25148
	for <pgsql-interfaces@postgreSQL.org>;
	Mon, 14 Dec 1998 20:25:15 -0500 (EST)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id UAA12468;
	Mon, 14 Dec 1998 20:25:03 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] The problem between libpq and libpgtcl for WIN32 
In-reply-to: Your message of Mon, 14 Dec 1998 19:12:23 +0900
	<000101be274a$3de91060$2801007e@cadzone.tpf.co.jp>
Date: Mon, 14 Dec 1998 20:25:03 -0500
Message-ID: <12466.913685103@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"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