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

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

Post by Peter Eisentraut - PostgreS » Sun, 08 Jul 2001 04:41:58

CVSROOT:        /home/projects/pgsql/cvsroot
Module name:    pgsql

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

Log message:
        Use CONNECTION_OK to determine whether startup phase is complete.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly


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

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. Import public folder in a database ?

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

4. Repost Of Request

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

6. URLConnections

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

8. Question about INGRES forms

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

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

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

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

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