> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Peter Eisentraut <[EMAIL PROTECTED]> 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
> Peter Eisentraut <[EMAIL PROTECTED]> 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 othe
Peter Eisentraut <[EMAIL PROTECTED]> 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
Peter Eisentraut <[EMAIL PROTECTED]> 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
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Peter Eisentraut <[EMAIL PROTECTED]> 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 Momjian <[EMAIL PROTECTED]> writes:
>> Peter Eisentraut <[EMAIL PROTECTED]> 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
>> ac
> Peter Eisentraut <[EMAIL PROTECTED]> 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
Peter Eisentraut <[EMAIL PROTECTED]> 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
OK, hterror removed.
> Bruce Momjian <[EMAIL PROTECTED]> 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
> , but only with nonstandard compilation options:
>
Bruce Momjian <[EMAIL PROTECTED]> 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
, but only with nonstandard compilation options:
#ifdef _XOPEN_SOURCE_EXTENDED
extern
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' undeclar
Looks like it needs a resolver include
LER
* Tom Lane <[EMAIL PROTECTED]> [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 (fir
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
> 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
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 hac
15 matches
Mail list logo
