  Date: Monday, November 13, 2000 @ 10:18:11
Author: momjian

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

Modified Files:
	postmaster.c 

-----------------------------  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


Mon, 13 Nov 2000 10:18:11 -0500 (EST)
momjian@postgresql.org
pgsql/src/backend/postmaster (postmaster.c)
I have to agree with Peter E. on this patch: it's poorly thought out.

I don't mind the idea of being able to relocate the socket file,
but the client-side interface they've chosen is silly.  Having to
add another switch to every client app is not reasonable --- it's
bad enough that you had to hack every one of the clients we supply,
but what of client apps that just use libpq or one of the other
interface libraries?  They'll be unable to talk to such a postmaster
without further work.

We should revert all the client-side changes from this patch, and
instead teach libpq and the other interfaces to treat a host name
that starts with a slash as being a path to a socket file (replacing
the default assumption of "/tmp").  Much cleaner, especially for
existing client apps.

			regards, tom lane

Mon, 13 Nov 2000 12:33:52 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: UUNET socket-file-location patch
> I have to agree with Peter E. on this patch: it's poorly thought out.

Now you tell me.  :-)

> I don't mind the idea of being able to relocate the socket file,
> but the client-side interface they've chosen is silly.  Having to
> add another switch to every client app is not reasonable --- it's
> bad enough that you had to hack every one of the clients we supply,
> but what of client apps that just use libpq or one of the other
> interface libraries?  They'll be unable to talk to such a postmaster
> without further work.

The only solution for other apps is to use the environment variable
PGUNXSOCKET or use PQconnectdb with unixsocket="lkjasdf".  

Overloading the hostname with a leading slash is another nice option. 
If I do that in libpq, then all the apps can benefit, right?

> We should revert all the client-side changes from this patch, and
> instead teach libpq and the other interfaces to treat a host name
> that starts with a slash as being a path to a socket file (replacing
> the default assumption of "/tmp").  Much cleaner, especially for
> existing client apps.

I can easily back out whatever you want.  Let me back out the client
changes, and hack libpq to handle the leading slash.  Sounds good.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 13 Nov 2000 12:51:57 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: UUNET socket-file-location patch
Actually, the thing doesn't even compile:

pqcomm.c: In function `StreamServerPort':
pqcomm.c:259: warning: implicit declaration of function `hstrerror'
pqcomm.c:259: `h_errno' undeclared (first use in this function)
pqcomm.c:259: (Each undeclared identifier is reported only once
pqcomm.c:259: for each function it appears in.)
make[3]: *** [pqcomm.o] Error 1

postmaster.c: In function `get_host_port':
postmaster.c:1338: warning: implicit declaration of function `hstrerror'
postmaster.c:1338: `h_errno' undeclared (first use in this function)
postmaster.c:1338: (Each undeclared identifier is reported only once
postmaster.c:1338: for each function it appears in.)
make[3]: *** [postmaster.o] Error 1

Please revert this patch, so I can get some work done?

			regards, tom lane

Mon, 13 Nov 2000 14:08:36 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Re: UUNET socket-file-location patch 
Looks like it needs a resolver include....

LER

* Tom Lane <tgl@sss.pgh.pa.us> [001113 13:11]:
> Actually, the thing doesn't even compile:
> 
> pqcomm.c: In function `StreamServerPort':
> pqcomm.c:259: warning: implicit declaration of function `hstrerror'
> pqcomm.c:259: `h_errno' undeclared (first use in this function)
> pqcomm.c:259: (Each undeclared identifier is reported only once
> pqcomm.c:259: for each function it appears in.)
> make[3]: *** [pqcomm.o] Error 1
> 
> postmaster.c: In function `get_host_port':
> postmaster.c:1338: warning: implicit declaration of function `hstrerror'
> postmaster.c:1338: `h_errno' undeclared (first use in this function)
> postmaster.c:1338: (Each undeclared identifier is reported only once
> postmaster.c:1338: for each function it appears in.)
> make[3]: *** [postmaster.o] Error 1
> 
> Please revert this patch, so I can get some work done?
> 
> 			regards, tom lane
-- 
Larry Rosenman                      http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Mon, 13 Nov 2000 13:21:04 -0600
Larry Rosenman <ler@lerctr.org>
Re: Re: UUNET socket-file-location patch
On BSDI, hstrerror is defined in netdb.h.  Do you have it anywhere?  Is
that a proper function call?


> Actually, the thing doesn't even compile:
> 
> pqcomm.c: In function `StreamServerPort':
> pqcomm.c:259: warning: implicit declaration of function `hstrerror'
> pqcomm.c:259: `h_errno' undeclared (first use in this function)
> pqcomm.c:259: (Each undeclared identifier is reported only once
> pqcomm.c:259: for each function it appears in.)
> make[3]: *** [pqcomm.o] Error 1
> 
> postmaster.c: In function `get_host_port':
> postmaster.c:1338: warning: implicit declaration of function `hstrerror'
> postmaster.c:1338: `h_errno' undeclared (first use in this function)
> postmaster.c:1338: (Each undeclared identifier is reported only once
> postmaster.c:1338: for each function it appears in.)
> make[3]: *** [postmaster.o] Error 1
> 
> Please revert this patch, so I can get some work done?
> 
> 			regards, tom lane
> 


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 13 Nov 2000 16:15:20 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: UUNET socket-file-location patch
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> On BSDI, hstrerror is defined in netdb.h.  Do you have it anywhere?  Is
> that a proper function call?

There is no hstrerror anywhere on HPUX.  h_errno is defined in
<netdb.h>, but only with nonstandard compilation options:

#ifdef _XOPEN_SOURCE_EXTENDED
extern int h_errno;
#endif

The man page for gethostbyname() points out that h_errno will be garbage
if the hostname was not resolved via a nameserver, anyway.

On the whole, this code looks much less than portable to me.

			regards, tom lane

Mon, 13 Nov 2000 16:29:26 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Re: UUNET socket-file-location patch 
OK, hterror removed.


> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > On BSDI, hstrerror is defined in netdb.h.  Do you have it anywhere?  Is
> > that a proper function call?
> 
> There is no hstrerror anywhere on HPUX.  h_errno is defined in
> <netdb.h>, but only with nonstandard compilation options:
> 
> #ifdef _XOPEN_SOURCE_EXTENDED
> extern int h_errno;
> #endif
> 
> The man page for gethostbyname() points out that h_errno will be garbage
> if the hostname was not resolved via a nameserver, anyway.
> 
> On the whole, this code looks much less than portable to me.
> 
> 			regards, tom lane
> 


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 13 Nov 2000 16:36:19 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: UUNET socket-file-location patch
Tom Lane writes:

> We should revert all the client-side changes from this patch, and
> instead teach libpq and the other interfaces to treat a host name
> that starts with a slash as being a path to a socket file (replacing
> the default assumption of "/tmp").  Much cleaner, especially for
> existing client apps.

Should the parameter determine the directory or the full file name?  I'd
go for the former, but it's not a strong case.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


Tue, 14 Nov 2000 18:45:36 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: Re: UUNET socket-file-location patch
Peter Eisentraut <peter_e@gmx.net> writes:
> Should the parameter determine the directory or the full file name?  I'd
> go for the former, but it's not a strong case.

Directory was what I had in mind too, but I'm not sure what Bruce
actually did ...

			regards, tom lane

Tue, 14 Nov 2000 12:48:35 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Re: UUNET socket-file-location patch 
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Should the parameter determine the directory or the full file name?  I'd
> > go for the former, but it's not a strong case.
> 
> Directory was what I had in mind too, but I'm not sure what Bruce
> actually did ...

I did whatever the patch did.  I believe it is the full path.  I believe
it is used here:

#define UNIXSOCK_PATH(sun,port,defpath) \
        ((defpath && defpath[0] != '\0') ? (strncpy((sun).sun_path,
defpath, sizeof((sun).sun_path)),
(sun).sun_path[sizeof((sun).sun_path)-1] = '\0') :
sprintf((sun).sun_path, "/tmp/.s.PGSQL.%d", (port)))


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 14 Nov 2000 18:54:35 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: UUNET socket-file-location patch
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Peter Eisentraut <peter_e@gmx.net> writes:
>>>> Should the parameter determine the directory or the full file name?  I'd
>>>> go for the former, but it's not a strong case.
>> 
>> Directory was what I had in mind too, but I'm not sure what Bruce
>> actually did ...

> I did whatever the patch did.  I believe it is the full path.  I believe
> it is used here:

> #define UNIXSOCK_PATH(sun,port,defpath) \
>         ((defpath && defpath[0] != '\0') ? (strncpy((sun).sun_path,
> defpath, sizeof((sun).sun_path)),
> (sun).sun_path[sizeof((sun).sun_path)-1] = '\0') :
> sprintf((sun).sun_path, "/tmp/.s.PGSQL.%d", (port)))

Hmm.  I think it would make more sense to make the parameter be just
the directory, not the full path including filename --- for one thing,
doing it like that renders the port-number parameter useless.  Why not

#define UNIXSOCK_PATH(sun,port,defpath) \
    snprintf((sun).sun_path, sizeof((sun).sun_path), "%s/.s.PGSQL.%d", \
             (((defpath) && *(defpath) != '\0') ? (defpath) : "/tmp"), \
             (port))

			regards, tom lane

Tue, 14 Nov 2000 23:28:52 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Re: UUNET socket-file-location patch 
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> Peter Eisentraut <peter_e@gmx.net> writes:
> >>>> Should the parameter determine the directory or the full file name?  I'd
> >>>> go for the former, but it's not a strong case.
> >> 
> >> Directory was what I had in mind too, but I'm not sure what Bruce
> >> actually did ...
> 
> > I did whatever the patch did.  I believe it is the full path.  I believe
> > it is used here:
> 
> > #define UNIXSOCK_PATH(sun,port,defpath) \
> >         ((defpath && defpath[0] != '\0') ? (strncpy((sun).sun_path,
> > defpath, sizeof((sun).sun_path)),
> > (sun).sun_path[sizeof((sun).sun_path)-1] = '\0') :
> > sprintf((sun).sun_path, "/tmp/.s.PGSQL.%d", (port)))
> 
> Hmm.  I think it would make more sense to make the parameter be just
> the directory, not the full path including filename --- for one thing,
> doing it like that renders the port-number parameter useless.  Why not
> 
> #define UNIXSOCK_PATH(sun,port,defpath) \
>     snprintf((sun).sun_path, sizeof((sun).sun_path), "%s/.s.PGSQL.%d", \
>              (((defpath) && *(defpath) != '\0') ? (defpath) : "/tmp"), \
>              (port))

I can do that.  Of course, I have to now change all the documentation to
match it.  :-)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 15 Nov 2000 09:15:50 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: UUNET socket-file-location patch
Bruce Momjian writes:

> > Hmm.  I think it would make more sense to make the parameter be just
> > the directory, not the full path including filename --- for one thing,
> > doing it like that renders the port-number parameter useless.  Why not
> > 
> > #define UNIXSOCK_PATH(sun,port,defpath) \
> >     snprintf((sun).sun_path, sizeof((sun).sun_path), "%s/.s.PGSQL.%d", \
> >              (((defpath) && *(defpath) != '\0') ? (defpath) : "/tmp"), \
> >              (port))
> 
> I can do that.  Of course, I have to now change all the documentation to
> match it.  :-)

Rather:

#define UNIXSOCK_PATH(sun,port,defpath) \
    snprintf((sun).sun_path, sizeof((sun).sun_path), "%s/.s.PGSQL.%d", \
             (defpath), (port))

and make "/tmp" the default in guc.c.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


Wed, 15 Nov 2000 17:38:12 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: Re: UUNET socket-file-location patch
Peter Eisentraut <peter_e@gmx.net> writes:
> #define UNIXSOCK_PATH(sun,port,defpath) \
>     snprintf((sun).sun_path, sizeof((sun).sun_path), "%s/.s.PGSQL.%d", \
>              (defpath), (port))

> and make "/tmp" the default in guc.c.

No, because this has to work on the client side too.  The default path
*must* be determined at compile time, or clients and servers will be
unable to find each other.

I wouldn't object to having "/tmp" be given as a macro PG_STD_SOCKET_DIR
in config.h, making it potentially configurable on a site-wide basis,
but that's as far as I think we can go.

			regards, tom lane

Wed, 15 Nov 2000 11:42:43 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Re: UUNET socket-file-location patch 
Tom Lane writes:

> > #define UNIXSOCK_PATH(sun,port,defpath) \
> >     snprintf((sun).sun_path, sizeof((sun).sun_path), "%s/.s.PGSQL.%d", \
> >              (defpath), (port))
> 
> > and make "/tmp" the default in guc.c.
> 
> No, because this has to work on the client side too.  The default path
> *must* be determined at compile time, or clients and servers will be
> unable to find each other.

The only difference between your snippet and mine is that yours sets the
default to "" and interprets it as "/tmp" when it is used, whereas mine
sets the default to "/tmp" to begin with.  Clients don't see the
difference.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


Wed, 15 Nov 2000 18:15:14 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: Re: UUNET socket-file-location patch 
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>>>> and make "/tmp" the default in guc.c.
>> 
>> No, because this has to work on the client side too.  The default path
>> *must* be determined at compile time, or clients and servers will be
>> unable to find each other.

> The only difference between your snippet and mine is that yours sets the
> default to "" and interprets it as "/tmp" when it is used, whereas mine
> sets the default to "/tmp" to begin with.  Clients don't see the
> difference.

Clients that don't contain guc.c are going to see a difference, no?
Where are they getting the default from?

			regards, tom lane

Wed, 15 Nov 2000 12:54:34 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Re: UUNET socket-file-location patch 
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Tom Lane writes:
> >>>> and make "/tmp" the default in guc.c.
> >> 
> >> No, because this has to work on the client side too.  The default path
> >> *must* be determined at compile time, or clients and servers will be
> >> unable to find each other.
> 
> > The only difference between your snippet and mine is that yours sets the
> > default to "" and interprets it as "/tmp" when it is used, whereas mine
> > sets the default to "/tmp" to begin with.  Clients don't see the
> > difference.
> 
> Clients that don't contain guc.c are going to see a difference, no?
> Where are they getting the default from?

Good point.  This macro is called by the backend, and the libpq frontend
code.  We would have to push the /tmp default into libpq code too, which
seems messier.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thu, 16 Nov 2000 00:18:48 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: UUNET socket-file-location patch
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> Peter Eisentraut <peter_e@gmx.net> writes:
> >>>> Should the parameter determine the directory or the full file name?  I'd
> >>>> go for the former, but it's not a strong case.
> >> 
> >> Directory was what I had in mind too, but I'm not sure what Bruce
> >> actually did ...
> 
> > I did whatever the patch did.  I believe it is the full path.  I believe
> > it is used here:
> 
> > #define UNIXSOCK_PATH(sun,port,defpath) \
> >         ((defpath && defpath[0] != '\0') ? (strncpy((sun).sun_path,
> > defpath, sizeof((sun).sun_path)),
> > (sun).sun_path[sizeof((sun).sun_path)-1] = '\0') :
> > sprintf((sun).sun_path, "/tmp/.s.PGSQL.%d", (port)))
> 
> Hmm.  I think it would make more sense to make the parameter be just
> the directory, not the full path including filename --- for one thing,
> doing it like that renders the port-number parameter useless.  Why not
> 
> #define UNIXSOCK_PATH(sun,port,defpath) \
>     snprintf((sun).sun_path, sizeof((sun).sun_path), "%s/.s.PGSQL.%d", \
>              (((defpath) && *(defpath) != '\0') ? (defpath) : "/tmp"), \
>              (port))
> 
> 			regards, tom lane
> 

OK, here is the diff to make the socket file option specify just a
directory, not a full path.  Documentation changes were also made.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

? Makefile.custom
? GNUmakefile
? Makefile.global
? log
? crtags
? backend/postgres
? backend/catalog/global.description
? backend/catalog/global.bki
? backend/catalog/template1.bki
? backend/catalog/template1.description
? backend/port/Makefile
? bin/initdb/initdb
? bin/initlocation/initlocation
? bin/ipcclean/ipcclean
? bin/pg_config/pg_config
? bin/pg_ctl/pg_ctl
? bin/pg_dump/pg_dump
? bin/pg_dump/pg_restore
? bin/pg_dump/pg_dumpall
? bin/pg_id/pg_id
? bin/pg_passwd/pg_passwd
? bin/pgaccess/pgaccess
? bin/pgtclsh/Makefile.tkdefs
? bin/pgtclsh/Makefile.tcldefs
? bin/pgtclsh/pgtclsh
? bin/pgtclsh/pgtksh
? bin/psql/psql
? bin/scripts/createlang
? include/config.h
? include/stamp-h
? interfaces/ecpg/lib/libecpg.so.3.2.0
? interfaces/ecpg/preproc/ecpg
? interfaces/libpgeasy/libpgeasy.so.2.1
? interfaces/libpgtcl/libpgtcl.so.2.1
? interfaces/libpq/libpq.so.2.1
? interfaces/perl5/blib
? interfaces/perl5/Makefile
? interfaces/perl5/pm_to_blib
? interfaces/perl5/Pg.c
? interfaces/perl5/Pg.bs
? pl/plperl/blib
? pl/plperl/Makefile
? pl/plperl/pm_to_blib
? pl/plperl/SPI.c
? pl/plperl/plperl.bs
? pl/plpgsql/src/libplpgsql.so.1.0
? pl/tcl/Makefile.tcldefs
Index: include/libpq/pqcomm.h
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/include/libpq/pqcomm.h,v
retrieving revision 1.45
diff -c -r1.45 pqcomm.h
*** include/libpq/pqcomm.h	2000/11/15 18:36:06	1.45
--- include/libpq/pqcomm.h	2000/11/22 01:33:54
***************
*** 51,66 ****
  /* Configure the UNIX socket address for the well known port. */
  
  #if defined(SUN_LEN)
- #define UNIXSOCK_PATH(sun,port,defpath) \
-         ((defpath && defpath[0] != '\0') ? (strncpy((sun).sun_path, defpath, sizeof((sun).sun_path)), (sun).sun_path[sizeof((sun).sun_path)-1] = '\0') : sprintf((sun).sun_path, "/tmp/.s.PGSQL.%d", (port)))
  #define UNIXSOCK_LEN(sun) \
          (SUN_LEN(&(sun)))
  #else
- #define UNIXSOCK_PATH(sun,port,defpath) \
-         ((defpath && defpath[0] != '\0') ? (strncpy((sun).sun_path, defpath, sizeof((sun).sun_path)), (sun).sun_path[sizeof((sun).sun_path)-1] = '\0') : sprintf((sun).sun_path, "/tmp/.s.PGSQL.%d", (port)))
  #define UNIXSOCK_LEN(sun) \
          (strlen((sun).sun_path)+ offsetof(struct sockaddr_un, sun_path))
  #endif
  
  /*
   *		We do this because sun_len is in BSD's struct, while others don't.
--- 51,65 ----
  /* Configure the UNIX socket address for the well known port. */
  
  #if defined(SUN_LEN)
  #define UNIXSOCK_LEN(sun) \
          (SUN_LEN(&(sun)))
  #else
  #define UNIXSOCK_LEN(sun) \
          (strlen((sun).sun_path)+ offsetof(struct sockaddr_un, sun_path))
  #endif
+ 
+ #define UNIXSOCK_PATH(sun,port,defpath) \
+         (snprintf((sun).sun_path, UNIXSOCK_LEN(sun), "%s/.s.PGSQL.%d", (defpath && *(defpath) != '\0') ? (defpath) : "/tmp", (port)))
  
  /*
   *		We do this because sun_len is in BSD's struct, while others don't.
Tue, 21 Nov 2000 20:37:51 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: UUNET socket-file-location patch