Message-Id: <3.0.32.19990726113102.00906680@mail.wavefire.com>
Date: Mon, 26 Jul 1999 11:31:02 -0700
To: pgsql-interfaces@postgreSQL.org
From: Swen Kabis <swen@wavefire.com>
Subject: Re: [INTERFACES] libpq - PQsetenv and its new sister functions
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"

At 08:32 PM 7/25/99 +0100, you wrote:

>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.


I think it would be better to declare it in libpq-fe.h


Swen

<bold>~

-----BEGIN GEEK CODE BLOCK-----

GCS/O d-(+) s:+>:- a- C++++ UB++$>++++$ P+ L++>++++$ E--

W++(++) N+ o? K? w--- O- M-- V-- PS+ PE@ Y PGP t++ 5++ X

R* tv++ b+++(+) DI++ D+++ G++ e++ h---->$ r+++ x**

-----END GEEK CODE BLOCK-----</bold>