Andrew Dunstan wrote:
> Bruce Momjian wrote:
> > We already do expose it:
> >
> > $ pg_config --sysconfdir
> > /usr/var/local/postgres/etc
> >
> >
>
> Speaking of this item, what do we want to do about the Windows situation
> where if the directory doesn't exist it reports nothing at a
Bruce Momjian wrote:
We already do expose it:
$ pg_config --sysconfdir
/usr/var/local/postgres/etc
Speaking of this item, what do we want to do about the Windows situation
where if the directory doesn't exist it reports nothing at all? I am
inclined to send back the outpu
Larry Rosenman wrote:
> Tom Lane wrote:
> > "Larry Rosenman" <[EMAIL PROTECTED]> writes:
> >>> Uh, it is an _admin_ function, not an application programmer
> >>> function.
> >
> >> but libpq is the only thing that knows where it is, and I had
> >> proposed a way for psql to use the function to get
Tom Lane wrote:
> "Larry Rosenman" <[EMAIL PROTECTED]> writes:
> >> Uh, it is an _admin_ function, not an application programmer
> >> function.
>
> > but libpq is the only thing that knows where it is, and I had proposed a
> > way for psql to use the function to get it.
>
> It'd make more sense f
Tom Lane wrote:
> "Larry Rosenman" <[EMAIL PROTECTED]> writes:
>>> Uh, it is an _admin_ function, not an application programmer
>>> function.
>
>> but libpq is the only thing that knows where it is, and I had
>> proposed a way for psql to use the function to get it.
>
> It'd make more sense for p
"Larry Rosenman" <[EMAIL PROTECTED]> writes:
>> Uh, it is an _admin_ function, not an application programmer
>> function.
> but libpq is the only thing that knows where it is, and I had proposed a
> way for psql to use the function to get it.
It'd make more sense for pg_config to expose this as o
Bruce Momjian wrote:
> Larry Rosenman wrote:
>> Bruce Momjian wrote:
>>> Larry Rosenman wrote:
Bruce Momjian wrote:
> Larry Rosenman wrote:
>> Tom Lane wrote:
>>> Bruce Momjian writes:
I thought about this. Attached is a patch you can use to
popen("pg_config") a
Larry Rosenman wrote:
> Bruce Momjian wrote:
> > Larry Rosenman wrote:
> >> Bruce Momjian wrote:
> >>> Larry Rosenman wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> >> I thought about this. Attached is a patch you can use to
> >> popen("pg_config") and then look for the thr
Tom Lane wrote:
> Bruce Momjian writes:
> > True, but if you go per-option, I can see adding a lot of them. That
> > seemed more messy.
>
> If there actually were a lot of options being proposed for addition,
> maybe, but I only see one on the table.
Well, SSL is one, multibyte is another. I c
Bruce Momjian wrote:
> Larry Rosenman wrote:
>> Bruce Momjian wrote:
>>> Larry Rosenman wrote:
Tom Lane wrote:
> Bruce Momjian writes:
>> I thought about this. Attached is a patch you can use to
>> popen("pg_config") and then look for the thread flag to
>> configure. One idea
Bruce Momjian writes:
> True, but if you go per-option, I can see adding a lot of them. That
> seemed more messy.
If there actually were a lot of options being proposed for addition,
maybe, but I only see one on the table.
regards, tom lane
---(e
"Larry Rosenman" <[EMAIL PROTECTED]> writes:
> I had made a proposal to expose the path used for pg_service.conf.
I don't remember that anymore, but my question about it would be "what's
the use case?" I don't see a particularly good reason why an app would
need to know that, whereas it's prett
Tom Lane wrote:
> Bruce Momjian writes:
> >> Tom Lane wrote:
> >>> Yeah, the last point seems like a killer objection :-(. It'd be
> >>> better to add some sort of libpq function to handle the issue.
> >>
> >> and when I've proposed libpq functions to expose compile-time
> >> constants, I've bee
Larry Rosenman wrote:
> Bruce Momjian wrote:
> > Larry Rosenman wrote:
> >> Tom Lane wrote:
> >>> Bruce Momjian writes:
> I thought about this. Attached is a patch you can use to
> popen("pg_config") and then look for the thread flag to configure.
> One idea would be to add this sa
Bruce Momjian writes:
>> Tom Lane wrote:
>>> Yeah, the last point seems like a killer objection :-(. It'd be
>>> better to add some sort of libpq function to handle the issue.
>>
>> and when I've proposed libpq functions to expose compile-time
>> constants, I've been shot down.
>>
>> How is th
Bruce Momjian wrote:
> Larry Rosenman wrote:
>> Tom Lane wrote:
>>> Bruce Momjian writes:
I thought about this. Attached is a patch you can use to
popen("pg_config") and then look for the thread flag to configure.
One idea would be to add this sample to our libpq documentation.
>>
Larry Rosenman wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> >> I thought about this. Attached is a patch you can use to
> >> popen("pg_config") and then look for the thread flag to configure.
> >> One idea would be to add this sample to our libpq documentation. The
> >> problem with the
Tom Lane wrote:
> Bruce Momjian writes:
>> I thought about this. Attached is a patch you can use to
>> popen("pg_config") and then look for the thread flag to configure.
>> One idea would be to add this sample to our libpq documentation. The
>> problem with the example is popen() overhead, pg_c
Bruce Momjian writes:
> I thought about this. Attached is a patch you can use to
> popen("pg_config") and then look for the thread flag to configure. One
> idea would be to add this sample to our libpq documentation. The
> problem with the example is popen() overhead, pg_config not in $PATH, or
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Fri, May 12, 2006 at 08:38:07PM -0400, Bruce Momjian wrote:
> > Is this like detecting of libpq is SSL-enabled? I see PQgetssl(). Do
> > we need to add a libpq function to return true/false for threading?
> > Slony requires a thr
On Fri, May 12, 2006 at 08:38:07PM -0400, Bruce Momjian wrote:
> Is this like detecting of libpq is SSL-enabled? I see PQgetssl(). Do
> we need to add a libpq function to return true/false for threading?
> Slony requires a threaded libpq, so it could do the test to prevent
> wrong configurations
From: Bruce Momjian > [EMAIL PROTECTED] wrote:> > Hi all> > > > I am writing an app that uses libpq, but because it is threaded I want to make sure that the dynamic> > library being used has been compiled with the right option.> > How do I do this?> > > > Is there a call such as "bool PQisThreadS
[EMAIL PROTECTED] wrote:
> Hi all
>
> I am writing an app that uses libpq, but because it is threaded I want to
> make sure that the dynamic library being used has been compiled with the
> right option.
> How do I do this?
>
> Is there a call such as "bool PQisThreadSafe()" that I can call?
[
23 matches
Mail list logo
