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>
