pg.ddx.io pgsql-interfaces@postgresql.org mailing list archivehelp / color / mirror / Atom feed
libpq - PQsetenv and its new sister functions 2+ messages / 2 participants [nested] [flat]
* libpq - PQsetenv and its new sister functions @ 1999-07-25 19:32 eem21@cam.ac.uk 0 siblings, 0 replies; 2+ messages in thread From: eem21@cam.ac.uk @ 1999-07-25 19:32 UTC (permalink / raw) To: 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. ^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: [INTERFACES] libpq - PQsetenv and its new sister functions @ 1999-07-26 18:31 Swen Kabis <swen@wavefire.com> 0 siblings, 0 replies; 2+ messages in thread From: Swen Kabis @ 1999-07-26 18:31 UTC (permalink / raw) To: pgsql-interfaces 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> ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~1999-07-26 18:31 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 1999-07-25 19:32 libpq - PQsetenv and its new sister functions eem21@cam.ac.uk 1999-07-26 18:31 Re: [INTERFACES] libpq - PQsetenv and its new sister functions Swen Kabis <swen@wavefire.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox