Received: from orange.csi.cam.ac.uk (exim@orange.csi.cam.ac.uk [131.111.8.77]) by hub.org (8.9.3/8.9.3) with ESMTP id PAA58882 for ; Sun, 25 Jul 1999 15:20:31 -0400 (EDT) (envelope-from ewan@cam.ac.uk) Received: from cmor.chu.cam.ac.uk ([131.111.202.213] helo=cam.ac.uk) by orange.csi.cam.ac.uk with esmtp (Exim 3.02 #1) id 118Tox-0002Pn-00 for pgsql-interfaces@postgreSQL.org; Sun, 25 Jul 1999 20:20:28 +0100 Date: Sun, 25 Jul 1999 20:32:56 +0100 (BST) From: eem21@cam.ac.uk Reply-To: eem21@cam.ac.uk Subject: libpq - PQsetenv and its new sister functions To: pgsql-interfaces@postgresql.org MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Message-Id: Further to my discussions with Tom Lane on this list last weekend, I have been re-arranging the connection functions in libpq to allow asynchronous connections. Part of this has been to create new functions that perform the duties of the existing function PQsetenv, but in a non-blocking manner. This involves passing the values of certain environment variables (PGDATESTYLE, PGTZ, et al) to the backend, as well as negotiating a client encoding if MULTIBYTE is defined. Now, PQsetenv is declared in fe-connect.c thus: /* XXX Why is this not static? */ void PQsetenv(PGconn *conn); It is not declared in libpq-fe.h, so currently those who are playing by the rules are unable to call this function for themselves. It seems to me that PQsetenv might be useful as part of the public API, and I can see no harm in doing so. What is clear, however, is that the functions I have created should have the same accessibility as PQsetenv; to do otherwise would be nonsensical. So, should I bring PQsetenv into the public API by declaring it in libpq-fe.h, and have my functions join it, or should I keep the new functions static (and probably leave PQsetenv non-static, with compatibility worries). My preference would be the former - does anyone disagree? Ewan Mellor.