pgsql/src/interfaces/libpq libpq-fe.h libpq-int.h

pgsql/src/interfaces/libpq libpq-fe.h libpq-int.h

Post by t.. » Sun, 04 Nov 2001 06:11:48



CVSROOT:        /cvsroot
Module name:    pgsql

Modified files:
        src/interfaces/libpq: libpq-fe.h libpq-int.h

Log message:
        Windows portability macros SOCK_ERRNO and SOCK_STRERROR should be in
        libpq-int.h, not cluttering application namespace in libpq-fe.h.

---------------------------(end of broadcast)---------------------------

 
 
 

1. pgsql/src/interfaces/libpq (fe-connect.c libpq-fe.h libpq-int.h libpqdll.def)


Author: momjian

Update of /home/projects/pgsql/cvsroot/pgsql/src/interfaces/libpq
     from hub.org:/home/projects/pgsql/tmp/cvs-serv65584/pgsql/src/interfaces/libpq

Modified Files:
        fe-connect.c libpq-fe.h libpq-int.h libpqdll.def

-----------------------------  Log Message  -----------------------------

UUNET is looking into offering PostgreSQL as a part of a managed web
hosting product, on both shared and dedicated machines.  We currently
offer Oracle and MySQL, and it would be a nice middle-ground.
However, as shipped, PostgreSQL lacks the following features we need
that MySQL has:

1. The ability to listen only on a particular IP address.  Each
   hosting customer has their own IP address, on which all of their
   servers (http, ftp, real media, etc.) run.
2. The ability to place the Unix-domain socket in a mode 700 directory.
   This allows us to automatically create an empty database, with an
   empty DBA password, for new or upgrading customers without having
   to interactively set a DBA password and communicate it to (or from)
   the customer.  This in turn cuts down our install and upgrade times.
3. The ability to connect to the Unix-domain socket from within a
   change-rooted environment.  We run CGI programs chrooted to the
   user's home directory, which is another reason why we need to be
   able to specify where the Unix-domain socket is, instead of /tmp.
4. The ability to, if run as root, open a pid file in /var/run as
   root, and then setuid to the desired user.  (mysqld -u can almost
   do this; I had to patch it, too).

The patch below fixes problem 1-3.  I plan to address #4, also, but
haven't done so yet.  These diffs are big enough that they should give
the PG development team something to think about in the meantime :-)
Also, I'm about to leave for 2 weeks' vacation, so I thought I'd get
out what I have, which works (for the problems it tackles), now.

With these changes, we can set up and run PostgreSQL with scripts the
same way we can with apache or proftpd or mysql.

In summary, this patch makes the following enhancements:

1. Adds an environment variable PGUNIXSOCKET, analogous to MYSQL_UNIX_PORT,
   and command line options -k --unix-socket to the relevant programs.
2. Adds a -h option to postmaster to set the hostname or IP address to
   listen on instead of the default INADDR_ANY.
3. Extends some library interfaces to support the above.
4. Fixes a few memory leaks in PQconnectdb().

The default behavior is unchanged from stock 7.0.2; if you don't use
any of these new features, they don't change the operation.

David J. MacKenzie

2. Btrieve 6.0??

3. pgsql/src/interfaces/libpq (fe-connect.c libpq-int.h)

4. How to select random records?

5. pgsql/src/interfaces/libpq fe-exec.c libpq-fe.h

6. using Access/data shaping and connection management

7. pgsql/src/interfaces/libpq fe-connect.c libpq- ...

8. Moving data form Access to SQL Server 6.5 (Looking for opinions)

9. pgsql/src/interfaces/libpq (libpq-fe.h)

10. pgsql/src/interfaces/libpq Makefile libpq-int.h

11. pgsql/src/interfaces/libpq fe-connect.c fe-misc.c

12. pgsql/src/interfaces/libpq (fe-connect.c fe-exec.c)

13. pgsql/src/interfaces/libpq fe-connect.c fe-exe ...h