Re: [INTERFACES] libpq - PQsetenv and its new sister functions
От | Swen Kabis |
---|---|
Тема | Re: [INTERFACES] libpq - PQsetenv and its new sister functions |
Дата | |
Msg-id | 3.0.32.19990726113102.00906680@mail.wavefire.com обсуждение исходный текст |
Список | 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>
В списке pgsql-interfaces по дате отправления: