Skip site navigation (1) Skip section navigation (2)

libpq - PQsetenv and its new sister functions

From: eem21(at)cam(dot)ac(dot)uk
To: pgsql-interfaces(at)postgresql(dot)org
Subject: libpq - PQsetenv and its new sister functions
Date: 1999-07-25 19:32:56
Message-ID: E118Tox-0002Pn-00@orange.csi.cam.ac.uk (view raw or flat)
Thread:
Lists: pgsql-interfaces
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.


pgsql-interfaces by date

Next:From: Martin JacksonDate: 1999-07-26 04:05:58
Subject: (no subject)
Previous:From: Byron NikolaidisDate: 1999-07-25 02:10:28
Subject: Re: [INTERFACES] More VB

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group