pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedthread-safe libpq and DBD::Pg
27+ messages / 9 participants
[nested] [flat]
* thread-safe libpq and DBD::Pg
@ 1998-08-07 18:19 Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 27+ messages in thread
From: Goran Thyni @ 1998-08-07 18:19 UTC (permalink / raw)
To: pgsql-interfaces; +Cc: PostgreSQL-development <hackers@postgresql.org>
When experimenting with threaded perl
I noticed I had to lock access to the database
a one user at the time in order get reliable (no SEGV).
Unfortunely it is 3 layer between my server and the wire,
DBI, DBD::Pg och libpq.
Thinking I would start from the bottom:
Has anyone any experience of the thread-safeness of libpq?
have a good weekend,
Göran
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [HACKERS] thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
@ 1998-08-08 18:30 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 00:51 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 08:16 ` Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
0 siblings, 2 replies; 27+ messages in thread
From: Tom Lane @ 1998-08-08 18:30 UTC (permalink / raw)
To: Goran Thyni <goran@bildbasen.se>; +Cc: pgsql-interfaces@postgreSQL.org, PostgreSQL-development <hackers@postgreSQL.org>
Goran Thyni <goran@bildbasen.se> writes:
> Has anyone any experience of the thread-safeness of libpq?
PQconnectdb() is not thread-safe, because it scribbles temporary
data in the static PQconninfoOptions array. You can get around
that easily enough by not using PQconnectdb (or PQconndefaults)
--- use PQsetdbLogin() instead. In any case the problem exists
only if different threads try to open database connections
at the same time.
As far as I can think at the moment, ordinary operations while
the database connection is open should be thread safe. That's
assuming that your libc (esp. malloc/free) is thread safe of course.
It also assumes that only one thread is using any one PGconn
object (at a time, anyway). Multiple threads using the same
PGconn to issue concurrent requests definitely will not work.
There is also some thread risk during connection shutdown because
libpq momentarily commandeers the SIGPIPE handler. I am thinking
it'd be nice to get rid of that code if possible --- see discussion
from a couple weeks ago on the hackers (or was it interfaces?) list.
I had thought a little bit about ripping out PQconnectdb's use of
changeable fields in PQconninfoOptions, but it looks like this
could break applications that access PQconninfoOptions.
Does anyone have any feelings about that, pro or con?
regards, tom lane
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [HACKERS] thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
@ 1998-08-09 00:51 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 03:12 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Bruce Momjian <maillist@candle.pha.pa.us>
1998-08-09 03:50 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Bruce Momjian <maillist@candle.pha.pa.us>
1 sibling, 2 replies; 27+ messages in thread
From: Tom Lane @ 1998-08-09 00:51 UTC (permalink / raw)
To: Goran Thyni <goran@bildbasen.se>; +Cc: pgsql-interfaces@postgreSQL.org, PostgreSQL-development <hackers@postgreSQL.org>
I wrote:
> Goran Thyni <goran@bildbasen.se> writes:
>> Has anyone any experience of the thread-safeness of libpq?
> There is also some thread risk during connection shutdown because
> libpq momentarily commandeers the SIGPIPE handler. I am thinking
> it'd be nice to get rid of that code if possible --- see discussion
> from a couple weeks ago on the hackers (or was it interfaces?) list.
I have removed that SIGPIPE hacking from closePGconn() in a patch
just submitted to pgsql-patches; that's one less thread safety violation
in libpq. However, whilst I was poking about in the libpq innards I
noticed a couple of other ones :-(.
PQprint() also manipulates the SIGPIPE handler in order to prevent
application termination if the pager subprocess it starts up decides
to quit early. This is a good thing, I think, but it does create
a problem if the app is multi-threaded and other threads would prefer
a different SIGPIPE setting. (I suppose if signal handlers are
thread-local in your environment then it's a non-issue anyway.)
I also noticed that PQoidStatus() returns a pointer to a static
char array, which is a classic thread-safety booboo. I am thinking
that the cleanest solution is for it to copy the OID number into
conn->errorMessage and return a pointer to that. This would mean
that the value would not be good after the next operation on the
PGconn object, but I wouldn't imagine that any apps hold onto the
pointer very long anyway --- they probably always feed it to atoi
immediately. (Actually, why the dickens doesn't this routine
return an Oid value directly? It could return InvalidOid in
case of trouble, just like PQftype does... but I suppose we don't
want to break application code just to make the API a tad cleaner.)
regards, tom lane
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [HACKERS] thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 00:51 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
@ 1998-08-09 03:12 ` Bruce Momjian <maillist@candle.pha.pa.us>
1 sibling, 0 replies; 27+ messages in thread
From: Bruce Momjian @ 1998-08-09 03:12 UTC (permalink / raw)
To: tgl@sss.pgh.pa.us; +Cc: goran@bildbasen.se; pgsql-interfaces; hackers@postgreSQL.org
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [HACKERS] thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 00:51 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
@ 1998-08-09 03:50 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-08-09 15:49 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 27+ messages in thread
From: Bruce Momjian @ 1998-08-09 03:50 UTC (permalink / raw)
To: tgl@sss.pgh.pa.us; +Cc: goran@bildbasen.se; pgsql-interfaces; hackers@postgreSQL.org
> I also noticed that PQoidStatus() returns a pointer to a static
> char array, which is a classic thread-safety booboo. I am thinking
> that the cleanest solution is for it to copy the OID number into
> conn->errorMessage and return a pointer to that. This would mean
> that the value would not be good after the next operation on the
> PGconn object, but I wouldn't imagine that any apps hold onto the
> pointer very long anyway --- they probably always feed it to atoi
> immediately. (Actually, why the dickens doesn't this routine
> return an Oid value directly? It could return InvalidOid in
> case of trouble, just like PQftype does... but I suppose we don't
> want to break application code just to make the API a tad cleaner.)
Yes, it is very silly that PQoidStatus() returns a char*. I believe it
was only done that way because it was pulling the oid out of the
cmdStatus field. We really should return an int. Perhaps we don't
because we would be hardcoding the oid type on the client side. By
default, we return all types as char *. I don't think we do this
anywhere else in the protocol.
This is a complete guess. I believe it was added by Vadim in 6.2 or
6.3.
Perhaps we could double-use the cmdStatus field, perhaps when they ask
for the oid, we put a null after the oid value, and return a pointer to
the inside of the cmdStatus field. If the call for PQcmdStatus(), we
remove the null and return the string. Strange, I admit.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [HACKERS] thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 00:51 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 03:50 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Bruce Momjian <maillist@candle.pha.pa.us>
@ 1998-08-09 15:49 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 17:34 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 1 reply; 27+ messages in thread
From: Tom Lane @ 1998-08-09 15:49 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: pgsql-interfaces; hackers@postgreSQL.org
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Yes, it is very silly that PQoidStatus() returns a char*. I believe it
> was only done that way because it was pulling the oid out of the
> cmdStatus field. We really should return an int. Perhaps we don't
> because we would be hardcoding the oid type on the client side.
Type Oid is already visible to libpq clients: it's returned by PQftype()
as the type code for attributes. I think encouraging clients to store
oids as type Oid rather than some-int-type-chosen-at-random would be a
good thing, not a bad thing.
However, improving the cleanliness of the API might not be worth the
cost of breaking application code, even though this routine is probably
not very widely used. Does anyone else have an opinion pro or con?
> Perhaps we could double-use the cmdStatus field, perhaps when they ask
> for the oid, we put a null after the oid value, and return a pointer to
> the inside of the cmdStatus field. If the call for PQcmdStatus(), we
> remove the null and return the string. Strange, I admit.
I had a variant of that idea: what's stored in cmdStatus looks like
INSERT oidvalue count
but there's a fair amount of room left over (cmdStatus is 40 bytes ...
and we could make it bigger if we wanted). We can make PQoidStatus
copy the oidvalue into the free space:
cmdStatus = "INSERT oidvalue count\0oidvalue\0"
and return a pointer to here ...............^
That way PQcmdStatus and PQoidStatus don't interfere with each other.
The result of PQoidStatus will still get zapped by the next interaction
with the backend, but at least it's not as transient as it would be in
the errorMessage field.
But, still, converting to an integer return value would be a *lot*
cleaner.
If we were going to do that, I'd be strongly inclined to change
PQcmdTuples to return an int (or more likely a long) as well.
I can't envision any situation where people aren't writing
atoi(PQcmdTuples(conn)) so why not save them the trouble...
regards, tom lane
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [HACKERS] thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 00:51 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 03:50 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Bruce Momjian <maillist@candle.pha.pa.us>
1998-08-09 15:49 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
@ 1998-08-09 17:34 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-08-09 23:01 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 27+ messages in thread
From: Bruce Momjian @ 1998-08-09 17:34 UTC (permalink / raw)
To: tgl@sss.pgh.pa.us; +Cc: pgsql-interfaces; hackers@postgreSQL.org
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > Yes, it is very silly that PQoidStatus() returns a char*. I believe it
> > was only done that way because it was pulling the oid out of the
> > cmdStatus field. We really should return an int. Perhaps we don't
> > because we would be hardcoding the oid type on the client side.
>
> Type Oid is already visible to libpq clients: it's returned by PQftype()
> as the type code for attributes. I think encouraging clients to store
> oids as type Oid rather than some-int-type-chosen-at-random would be a
> good thing, not a bad thing.
>
> However, improving the cleanliness of the API might not be worth the
> cost of breaking application code, even though this routine is probably
> not very widely used. Does anyone else have an opinion pro or con?
>
> > Perhaps we could double-use the cmdStatus field, perhaps when they ask
> > for the oid, we put a null after the oid value, and return a pointer to
> > the inside of the cmdStatus field. If the call for PQcmdStatus(), we
> > remove the null and return the string. Strange, I admit.
>
> I had a variant of that idea: what's stored in cmdStatus looks like
> INSERT oidvalue count
> but there's a fair amount of room left over (cmdStatus is 40 bytes ...
> and we could make it bigger if we wanted). We can make PQoidStatus
> copy the oidvalue into the free space:
> cmdStatus = "INSERT oidvalue count\0oidvalue\0"
> and return a pointer to here ...............^
> That way PQcmdStatus and PQoidStatus don't interfere with each other.
> The result of PQoidStatus will still get zapped by the next interaction
> with the backend, but at least it's not as transient as it would be in
> the errorMessage field.
>
> But, still, converting to an integer return value would be a *lot*
> cleaner.
>
> If we were going to do that, I'd be strongly inclined to change
> PQcmdTuples to return an int (or more likely a long) as well.
> I can't envision any situation where people aren't writing
> atoi(PQcmdTuples(conn)) so why not save them the trouble...
Another idea I had was to a char* field to the result structure.
Initialize it to NULL, then when they want oidStatus, we malloc() some
memory, assign it to our char*, and copy the string into there, and
return that to the user. If we get called later, we can re-use the
memory, and free() it when we free the PQresult.
It was added in 6.2.
If we change it, we will have to require people using those calls to
modify their apps, rather than just relink with the new libpq. However,
old binaries will run fine because they would be linked to the old
libpq.
php3 uses PQoidStatus, so I can imagine great problems if we change the
libpq interface. I am afraid we are stuck with char*.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [HACKERS] thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 00:51 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 03:50 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Bruce Momjian <maillist@candle.pha.pa.us>
1998-08-09 15:49 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 17:34 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Bruce Momjian <maillist@candle.pha.pa.us>
@ 1998-08-09 23:01 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 23:35 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 1 reply; 27+ messages in thread
From: Tom Lane @ 1998-08-09 23:01 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: pgsql-interfaces; hackers@postgreSQL.org
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> php3 uses PQoidStatus, so I can imagine great problems if we change the
> libpq interface. I am afraid we are stuck with char*.
Yeah, I can't really see breaking applications just for a marginal
improvement in cleanliness.
There is a possible compromise however: we could leave PQcmdTuples and
PQoidStatus defined as-is (but do something to get rid of PQoidStatus'
use of a static return area), and add two more functions that have more
reasonable return conventions. The documentation could describe the
older functions as deprecated.
Perhaps the int-returning forms could be named "PQCmdTuples" and
"PQOidStatus" (note difference in capitalization) ... unless someone
has a better idea.
Does anyone think this is worth the trouble, or shall we leave bad
enough alone?
I do intend to get rid of the static return area for PQoidStatus in any
case. I'd also like to fix the problem with PQconninfoOptions not being
treated as a constant (specifically, the "val" fields are being used as
working storage). Is anyone aware of any applications that would be
broken by removing "val" from the PQconninfoOption struct?
regards, tom lane
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [HACKERS] thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 00:51 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 03:50 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Bruce Momjian <maillist@candle.pha.pa.us>
1998-08-09 15:49 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 17:34 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Bruce Momjian <maillist@candle.pha.pa.us>
1998-08-09 23:01 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
@ 1998-08-09 23:35 ` Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 0 replies; 27+ messages in thread
From: Bruce Momjian @ 1998-08-09 23:35 UTC (permalink / raw)
To: tgl@sss.pgh.pa.us; +Cc: pgsql-interfaces; hackers@postgreSQL.org
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > php3 uses PQoidStatus, so I can imagine great problems if we change the
> > libpq interface. I am afraid we are stuck with char*.
>
> Yeah, I can't really see breaking applications just for a marginal
> improvement in cleanliness.
>
> There is a possible compromise however: we could leave PQcmdTuples and
> PQoidStatus defined as-is (but do something to get rid of PQoidStatus'
> use of a static return area), and add two more functions that have more
> reasonable return conventions. The documentation could describe the
> older functions as deprecated.
>
> Perhaps the int-returning forms could be named "PQCmdTuples" and
> "PQOidStatus" (note difference in capitalization) ... unless someone
> has a better idea.
>
> Does anyone think this is worth the trouble, or shall we leave bad
> enough alone?
Perhaps we can leave the change for a time when we want to change the
libpq interface in a more significant way. Having two functions just
seems like a waste for such a rarely-called fuction.
>
> I do intend to get rid of the static return area for PQoidStatus in any
> case. I'd also like to fix the problem with PQconninfoOptions not being
> treated as a constant (specifically, the "val" fields are being used as
> working storage). Is anyone aware of any applications that would be
> broken by removing "val" from the PQconninfoOption struct?
>
> regards, tom lane
>
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
@ 1998-08-09 08:16 ` Goran Thyni <goran@bildbasen.se>
1998-08-09 15:33 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 27+ messages in thread
From: Goran Thyni @ 1998-08-09 08:16 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-interfaces
Tom Lane wrote:
>
> Goran Thyni <goran@bildbasen.se> writes:
> > Has anyone any experience of the thread-safeness of libpq?
>
> PQconnectdb() is not thread-safe, because it scribbles temporary
> data in the static PQconninfoOptions array. You can get around
> that easily enough by not using PQconnectdb (or PQconndefaults)
> --- use PQsetdbLogin() instead. In any case the problem exists
> only if different threads try to open database connections
> at the same time.
> [...}
Tom,
thanks for the reply.
DBD::Pg dos indeed use PQconnectdb(),
but at least in my light test I get SEGV in $sth->fetch.
The problems are probably somewhere in DBDI or DBD::Pg or
somewhere in the interaction of the parts.
I am looking into how much work a "pure Perl" interface
should amount to. Using native perl IO and pgsql-fe/be-protocol
should make "pgsql-clienting" even more portable over platforms.
regards,
Göran
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 08:16 ` Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
@ 1998-08-09 15:33 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 17:13 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
0 siblings, 1 reply; 27+ messages in thread
From: Tom Lane @ 1998-08-09 15:33 UTC (permalink / raw)
To: Goran Thyni <goran@bildbasen.se>; +Cc: pgsql-interfaces
Goran Thyni <goran@bildbasen.se> writes:
> DBD::Pg dos indeed use PQconnectdb(),
> but at least in my light test I get SEGV in $sth->fetch.
> The problems are probably somewhere in DBDI or DBD::Pg or
> somewhere in the interaction of the parts.
FWIW, I finally got around to installing Perl5 (5.004 pl4 to
be specific), and so far the perl5 interface supplied with pgsql
seems to work fine. I only just now realized that what you
are talking about is something different ... the code included
in the distribution calls itself Pg not DBD::Pg. What versions
of everything are you using?
> I am looking into how much work a "pure Perl" interface
> should amount to. Using native perl IO and pgsql-fe/be-protocol
> should make "pgsql-clienting" even more portable over platforms.
Of course, it will also mean that you have to maintain that code
every time we change the fe/be protocol ... there is a change
upcoming for 6.4.
regards, tom lane
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 08:16 ` Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 15:33 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
@ 1998-08-09 17:13 ` Goran Thyni <goran@bildbasen.se>
1998-08-09 22:51 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 27+ messages in thread
From: Goran Thyni @ 1998-08-09 17:13 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-interfaces
Tom Lane wrote:
>
> Goran Thyni <goran@bildbasen.se> writes:
> > DBD::Pg dos indeed use PQconnectdb(),
> > but at least in my light test I get SEGV in $sth->fetch.
> > The problems are probably somewhere in DBDI or DBD::Pg or
> > somewhere in the interaction of the parts.
>
> FWIW, I finally got around to installing Perl5 (5.004 pl4 to
> be specific), and so far the perl5 interface supplied with pgsql
> seems to work fine. I only just now realized that what you
> are talking about is something different ... the code included
> in the distribution calls itself Pg not DBD::Pg. What versions
> of everything are you using?
I am using perl 5.005_01 with threads support and DBI/DBD::Pg.
DBI/DBD is the "standard" RDBMS-interface for perl available
from CPAN.
> > I am looking into how much work a "pure Perl" interface
> > should amount to. Using native perl IO and pgsql-fe/be-protocol
> > should make "pgsql-clienting" even more portable over platforms.
>
> Of course, it will also mean that you have to maintain that code
> every time we change the fe/be protocol ... there is a change
> upcoming for 6.4.
I have done some experimenting:
The easy parts are done (if not cleanly), connect/exec/close.
The hairy parts is to extract row descriptors and tuples
from select/fetch statements.
I am working against the current CVS tree, are there more
protocol changes in the pipeline?
regards,
Göran.
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 08:16 ` Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 15:33 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 17:13 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
@ 1998-08-09 22:51 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-08-10 07:19 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
0 siblings, 1 reply; 27+ messages in thread
From: Tom Lane @ 1998-08-09 22:51 UTC (permalink / raw)
To: Goran Thyni <goran@bildbasen.se>; +Cc: pgsql-interfaces
Goran Thyni <goran@bildbasen.se> writes:
> I am using perl 5.005_01 with threads support and DBI/DBD::Pg.
> DBI/DBD is the "standard" RDBMS-interface for perl available
> from CPAN.
Hmm. Well, I'm afraid I have too much on my plate already to go chasing
an incompatibility with someone else's software. If you or someone else
can track down what the problem is, I'll gladly help fix libpq (if
that's what needs fixed) ... but I can't spare the time right now to
chase a problem that doesn't show up in my setup.
>> Of course, it will also mean that you have to maintain that code
>> every time we change the fe/be protocol ... there is a change
>> upcoming for 6.4.
> I am working against the current CVS tree, are there more
> protocol changes in the pipeline?
You're in good shape then; we agreed several weeks ago that there would
be no more FE-to-BE link protocol changes for 6.4. I was afraid you
might be working from 6.3.2 sources, that's all.
regards, tom lane
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 08:16 ` Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 15:33 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 17:13 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 22:51 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
@ 1998-08-10 07:19 ` Goran Thyni <goran@bildbasen.se>
1998-08-10 16:44 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Edmund Mergl <E.Mergl@bawue.de>
1998-08-11 07:47 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Herouth Maoz <herouth@oumail.openu.ac.il>
0 siblings, 2 replies; 27+ messages in thread
From: Goran Thyni @ 1998-08-10 07:19 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-interfaces@postgreSQL.org, Edmund Mergl <E.Mergl@bawue.de>
Tom,
Tom Lane wrote:
>
> Goran Thyni <goran@bildbasen.se> writes:
> > I am using perl 5.005_01 with threads support and DBI/DBD::Pg.
> > DBI/DBD is the "standard" RDBMS-interface for perl available
> > from CPAN.
>
> Hmm. Well, I'm afraid I have too much on my plate already to go chasing
> an incompatibility with someone else's software. If you or someone else
> can track down what the problem is, I'll gladly help fix libpq (if
> that's what needs fixed) ... but I can't spare the time right now to
> chase a problem that doesn't show up in my setup.
Since there are 3 pcs of s/w involved (all 3 with many lines of C-code)
and non of them are really well tested in a threaded environment
it is a real kludge.
I understand anyone who do not want to stick his head into that,
I pulled my own back and started experimenting with my "pure perl"
interface instead.
Your work cleaning up libpq will be appriciated by lots of programmers
out there.
As a status report on my module, it now fetch records OK too.
On the ToDo-list:
* INET-socket support (now it is Unix domain sockets only)
* explicit cursor support
* BLOB-support
* clean-up of error handling/reporting
* test suite
* DBI-DBD layer on top of standard module
I will release a snap-shot as soon as it is cleaned up a bit and
somewhat more tested.
regards,
--
---------------------------------------------
Göran Thyni, sysadm, JMS Bildbasen, Kiruna
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 08:16 ` Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 15:33 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 17:13 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 22:51 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-10 07:19 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
@ 1998-08-10 16:44 ` Edmund Mergl <E.Mergl@bawue.de>
1998-08-11 12:22 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1 sibling, 1 reply; 27+ messages in thread
From: Edmund Mergl @ 1998-08-10 16:44 UTC (permalink / raw)
To: Goran Thyni <goran@bildbasen.se>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-interfaces
Goran Thyni wrote:
>
> Tom,
>
> Tom Lane wrote:
> >
> > Goran Thyni <goran@bildbasen.se> writes:
> > > I am using perl 5.005_01 with threads support and DBI/DBD::Pg.
> > > DBI/DBD is the "standard" RDBMS-interface for perl available
> > > from CPAN.
> >
> > Hmm. Well, I'm afraid I have too much on my plate already to go chasing
> > an incompatibility with someone else's software. If you or someone else
> > can track down what the problem is, I'll gladly help fix libpq (if
> > that's what needs fixed) ... but I can't spare the time right now to
> > chase a problem that doesn't show up in my setup.
>
> Since there are 3 pcs of s/w involved (all 3 with many lines of C-code)
> and non of them are really well tested in a threaded environment
> it is a real kludge.
> I understand anyone who do not want to stick his head into that,
> I pulled my own back and started experimenting with my "pure perl"
> interface instead.
> Your work cleaning up libpq will be appriciated by lots of programmers
> out there.
>
> As a status report on my module, it now fetch records OK too.
> On the ToDo-list:
> * INET-socket support (now it is Unix domain sockets only)
> * explicit cursor support
> * BLOB-support
> * clean-up of error handling/reporting
> * test suite
> * DBI-DBD layer on top of standard module
> I will release a snap-shot as soon as it is cleaned up a bit and
> somewhat more tested.
>
> regards,
> --
> ---------------------------------------------
> Göran Thyni, sysadm, JMS Bildbasen, Kiruna
I suggest to spend the effort on making libpq thread safe.
Otherwise we end up with two DBD modules for postgres.
If you prepare a module, which does not depend on libpq,
you will have much more effort on keeping it up to date.
The main goal of an interface like libpq is to avoid such
dependencies.
Edmund
--
Edmund Mergl mailto:E.Mergl@bawue.de
Im Haldenhau 9 http://www.bawue.de/~mergl
70565 Stuttgart fon: +49 711 747503
Germany
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 08:16 ` Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 15:33 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 17:13 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 22:51 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-10 07:19 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-10 16:44 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Edmund Mergl <E.Mergl@bawue.de>
@ 1998-08-11 12:22 ` Goran Thyni <goran@bildbasen.se>
1998-08-11 14:51 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-12 06:03 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Edmund Mergl <E.Mergl@bawue.de>
0 siblings, 2 replies; 27+ messages in thread
From: Goran Thyni @ 1998-08-11 12:22 UTC (permalink / raw)
To: Edmund Mergl <E.Mergl@bawue.de>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-interfaces
Edmund,
I certainly respect your opinions and take note. We have used your
DBD::Pg-module
in several projects here with great success.
This is the conclusions I have reach:
* A "pure perl"-interface is useful for
- systems without decent C-compiler
- systems not supported by libpq
(there is already a pure TCL interface, isn't it?)
- in other special applications where "pure perl" is preferable.
* I will release my module, probably called PgSQL since,
- I need a "pure perl" interface for a couple of project
- The basic module is mostly done already
- Why not share?
* I will *NOT* make a DBD interface, because
- I don't need it
- the C-code in DBI make the arguments for "pure perl" mute
- It would confuse J. Random Looser and friends :-)
As I see it there is a niche for all three perl interfaces:
* DBI/DBD::Pg:
excellent portability across RDBMSs and nice standard API
makes it the natural choise for most project.
* Pg:
the choice where low-level access and maximum performance is needed
* PgSQL:
"pure perl" with OO-design makes it easily customizable for
PostgreSQL-only applications.
Maybe I will look at thread-safety for DBI/DBD::Pg/libpq but
debugging C-based perl-modules is pretty time consuming
(I wrote the DBD::Informix4 module a couple of yeasr ago).
Combine that with threads/debugging headache and isn't
so funny anymore. :-)
regards,
--
---------------------------------------------
Göran Thyni, sysadm, JMS Bildbasen, Kiruna
---------------------------------------------------------------
Edmund Mergl wrote:
> I suggest to spend the effort on making libpq thread safe.
> Otherwise we end up with two DBD modules for postgres.
> If you prepare a module, which does not depend on libpq,
> you will have much more effort on keeping it up to date.
> The main goal of an interface like libpq is to avoid such
> dependencies.
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 08:16 ` Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 15:33 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 17:13 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 22:51 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-10 07:19 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-10 16:44 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Edmund Mergl <E.Mergl@bawue.de>
1998-08-11 12:22 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
@ 1998-08-11 14:51 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-08-11 16:50 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Hannu Krosing <hannu@trust.ee>
1998-08-12 14:04 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Eric Marsden <emarsden@mail.dotcom.fr>
1 sibling, 2 replies; 27+ messages in thread
From: Tom Lane @ 1998-08-11 14:51 UTC (permalink / raw)
To: Goran Thyni <goran@bildbasen.se>; +Cc: pgsql-interfaces
Goran Thyni <goran@bildbasen.se> writes:
> * A "pure perl"-interface is useful for
> - systems without decent C-compiler
> - systems not supported by libpq
> (there is already a pure TCL interface, isn't it?)
I agree that a "pure Perl" or "pure Tcl" front end would be more
easily portable than what we have. It'd probably be slower, but
maybe not so much slower as to be a problem.
The present libpgtcl is NOT pure Tcl --- it is a C-coded Tcl extension,
besides which it is layered on top of libpq.
I think I remember someone speculating about writing a pure Tcl
front end by programming directly to the socket-level FE/BE interface,
but I haven't heard about any results.
regards, tom lane
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 08:16 ` Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 15:33 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 17:13 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 22:51 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-10 07:19 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-10 16:44 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Edmund Mergl <E.Mergl@bawue.de>
1998-08-11 12:22 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-11 14:51 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
@ 1998-08-11 16:50 ` Hannu Krosing <hannu@trust.ee>
1998-08-11 13:13 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg JohnDz <John_dzilvelis@valpak.com>
1998-08-12 14:29 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Eric Marsden <emarsden@mail.dotcom.fr>
1 sibling, 2 replies; 27+ messages in thread
From: Hannu Krosing @ 1998-08-11 16:50 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-interfaces@postgreSQL.org, Goran Thyni <goran@bildbasen.se>
Tom Lane wrote:
>
> Goran Thyni <goran@bildbasen.se> writes:
> > * A "pure perl"-interface is useful for
> > - systems without decent C-compiler
> > - systems not supported by libpq
> > (there is already a pure TCL interface, isn't it?)
>
> I agree that a "pure Perl" or "pure Tcl" front end would be more
> easily portable than what we have. It'd probably be slower, but
> maybe not so much slower as to be a problem.
I once did an incomplete "pure Python" PgSQL (v6.2) interface, which ran
on both Linux and Win32. It was not that much slower.
> The present libpgtcl is NOT pure Tcl --- it is a C-coded Tcl extension,
> besides which it is layered on top of libpq.
>
> I think I remember someone speculating about writing a pure Tcl
> front end by programming directly to the socket-level FE/BE interface,
> but I haven't heard about any results.
I've got the impression that there is currently a pure Tcl interface
as well that some use with pgAccess on win32.
Hannu
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 08:16 ` Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 15:33 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 17:13 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 22:51 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-10 07:19 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-10 16:44 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Edmund Mergl <E.Mergl@bawue.de>
1998-08-11 12:22 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-11 14:51 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-11 16:50 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Hannu Krosing <hannu@trust.ee>
@ 1998-08-11 13:13 ` JohnDz <John_dzilvelis@valpak.com>
1 sibling, 0 replies; 27+ messages in thread
From: JohnDz @ 1998-08-11 13:13 UTC (permalink / raw)
To: pgsql-interfaces
> > I think I remember someone speculating about writing a pure Tcl
> > front end by programming directly to the socket-level FE/BE interface,
> > but I haven't heard about any results.
>
> I've got the impression that there is currently a pure Tcl interface
> as well that some use with pgAccess on win32.
>
> Hannu
I am not sure what "pure" means , but there is a tcl script equivalent
of libpgtcl.so which is called pgsql.tcl. It is available from the same
site that you get pgaccess
I needed it to enable running pgaccess on a MacOS client. Works fine.
--
-----------------------------------------------------------------
|John Dzilvelis |
-----------------------------------------------------------------
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 08:16 ` Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 15:33 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 17:13 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 22:51 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-10 07:19 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-10 16:44 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Edmund Mergl <E.Mergl@bawue.de>
1998-08-11 12:22 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-11 14:51 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-11 16:50 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Hannu Krosing <hannu@trust.ee>
@ 1998-08-12 14:29 ` Eric Marsden <emarsden@mail.dotcom.fr>
1998-08-12 14:48 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 27+ messages in thread
From: Eric Marsden @ 1998-08-12 14:29 UTC (permalink / raw)
To: pgsql-interfaces
>>>>> "HK" == Hannu Krosing <hannu@trust.ee> writes:
>>>>> "TL" == Tom Lane <tgl@sss.pgh.pa.us> writes:
TL> The present libpgtcl is NOT pure Tcl --- it is a C-coded Tcl
TL> extension, besides which it is layered on top of libpq.
This is my impression too: in postgresql-6.3.2/src/interfaces/libpgtcl/
there are C files which reference functions like PQconnectdb. However,
the documentation for libpgtcl states (this is from the top of
postgresql-6.3.2/doc/src/sgml/libpgtcl.sgml)
pgtcl is a tcl package for front-end programs to interface with
<ProductName>Postgres</ProductName> backends. pgtcl does not use
the libpq library but communicates to the backend directly via the
frontend-backend protocol. Thus, it is more efficient than previous
postgres->tcl bindings which are layered on top of libpq. In
addition, pgtcl can handle multiple backend connections from a
single frontend application.
The documentation looks wrong, or perhaps it is talking about a
development version of libpgtcl? Should I report a documentation bug?
HK> I've got the impression that there is currently a pure Tcl interface
HK> as well that some use with pgAccess on win32.
This is ftp://ftp.flex.ro/pub/pgaccess/pgsql.tcl (Tcl interface at the
socket level).
--
Eric Marsden
emarsden @ mail.dotcom.fr
It's elephants all the way down
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 08:16 ` Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 15:33 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 17:13 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 22:51 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-10 07:19 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-10 16:44 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Edmund Mergl <E.Mergl@bawue.de>
1998-08-11 12:22 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-11 14:51 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-11 16:50 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Hannu Krosing <hannu@trust.ee>
1998-08-12 14:29 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Eric Marsden <emarsden@mail.dotcom.fr>
@ 1998-08-12 14:48 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 27+ messages in thread
From: Tom Lane @ 1998-08-12 14:48 UTC (permalink / raw)
To: emarsden@mail.dotcom.fr; +Cc: pgsql-interfaces
Eric Marsden <emarsden@mail.dotcom.fr> writes:
>>>>>> "TL" == Tom Lane <tgl@sss.pgh.pa.us> writes:
TL> The present libpgtcl is NOT pure Tcl --- it is a C-coded Tcl
TL> extension, besides which it is layered on top of libpq.
> the documentation for libpgtcl states (this is from the top of
> postgresql-6.3.2/doc/src/sgml/libpgtcl.sgml)
> pgtcl is a tcl package for front-end programs to interface with
> <ProductName>Postgres</ProductName> backends. pgtcl does not use
> the libpq library but communicates to the backend directly via the
> frontend-backend protocol. Thus, it is more efficient than previous
> postgres->tcl bindings which are layered on top of libpq. In
> addition, pgtcl can handle multiple backend connections from a
> single frontend application.
Yeah, that paragraph is all wet --- perhaps there once was a libpgtcl
written that way, but the current distribution certainly is not it.
I took that para out of the CVS sources some time ago.
regards, tom lane
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 08:16 ` Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 15:33 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 17:13 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 22:51 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-10 07:19 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-10 16:44 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Edmund Mergl <E.Mergl@bawue.de>
1998-08-11 12:22 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-11 14:51 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
@ 1998-08-12 14:04 ` Eric Marsden <emarsden@mail.dotcom.fr>
1998-08-12 14:33 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 27+ messages in thread
From: Eric Marsden @ 1998-08-12 14:04 UTC (permalink / raw)
To: pgsql-interfaces
>>>>> "TL" == Tom Lane <tgl@sss.pgh.pa.us> writes:
TL> I think I remember someone speculating about writing a pure Tcl
TL> front end by programming directly to the socket-level FE/BE interface,
TL> but I haven't heard about any results.
Can the FE/BE interface be expected to remain stable over time? As
much so as libpq?
--
Eric Marsden
emarsden @ mail.dotcom.fr
It's elephants all the way down
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 08:16 ` Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 15:33 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 17:13 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 22:51 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-10 07:19 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-10 16:44 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Edmund Mergl <E.Mergl@bawue.de>
1998-08-11 12:22 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-11 14:51 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-12 14:04 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Eric Marsden <emarsden@mail.dotcom.fr>
@ 1998-08-12 14:33 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 27+ messages in thread
From: Tom Lane @ 1998-08-12 14:33 UTC (permalink / raw)
To: emarsden@mail.dotcom.fr; +Cc: pgsql-interfaces
Eric Marsden <emarsden@mail.dotcom.fr> writes:
>>>>>> "TL" == Tom Lane <tgl@sss.pgh.pa.us> writes:
TL> I think I remember someone speculating about writing a pure Tcl
TL> front end by programming directly to the socket-level FE/BE interface,
TL> but I haven't heard about any results.
> Can the FE/BE interface be expected to remain stable over time? As
> much so as libpq?
Well, we changed it significantly for 6.4, so I wouldn't care to promise
it'll never change again. BUT: thanks to the fact that the client sends
a protocol version number at the start of a session, the server can and
does support old-protocol clients. So piecemeal updates of client
libraries seem feasible. I'd be a lot more worried about proliferating
clients that know the wire-level protocol if this were not so.
It occurs to me that there is a potential versioning bug in the way
libpq deals with this issue: it sends out the version number with
sp.protoVersion = (ProtocolVersion) htonl(PG_PROTOCOL_LATEST);
But PG_PROTOCOL_LATEST is defined (in some backend include file or
other) as the latest protocol version supported by the *server*.
Thus, merely recompiling libpq against source files of an updated
server will cause it to claim that it speaks the latest protocol
version, whether or not you've actually touched libpq.
This is bogus.
I think libpq needs to have its *own* constant defining what protocol
version number it speaks, which you'd have to update manually whenever
you change libpq to handle a different version.
Of course, the same goes for any other client library that deals with
the wire protocol directly.
regards, tom lane
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 08:16 ` Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 15:33 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 17:13 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 22:51 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-10 07:19 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-10 16:44 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Edmund Mergl <E.Mergl@bawue.de>
1998-08-11 12:22 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
@ 1998-08-12 06:03 ` Edmund Mergl <E.Mergl@bawue.de>
1 sibling, 0 replies; 27+ messages in thread
From: Edmund Mergl @ 1998-08-12 06:03 UTC (permalink / raw)
To: Goran Thyni <goran@bildbasen.se>; +Cc: pgsql-interfaces
Goran Thyni wrote:
>
> Edmund,
>
> I certainly respect your opinions and take note. We have used your
> DBD::Pg-module
> in several projects here with great success.
>
> This is the conclusions I have reach:
>
> * A "pure perl"-interface is useful for
> - systems without decent C-compiler
> - systems not supported by libpq
> (there is already a pure TCL interface, isn't it?)
> - in other special applications where "pure perl" is preferable.
> * I will release my module, probably called PgSQL since,
> - I need a "pure perl" interface for a couple of project
> - The basic module is mostly done already
> - Why not share?
> * I will *NOT* make a DBD interface, because
> - I don't need it
> - the C-code in DBI make the arguments for "pure perl" mute
> - It would confuse J. Random Looser and friends :-)
>
ok, I agree. I thought you are just working on a second DBD module
with the additional feature to be thread safe. A pure perl module
is certainly interesting for many people.
Edmund
--
Edmund Mergl mailto:E.Mergl@bawue.de
Im Haldenhau 9 http://www.bawue.de/~mergl
70565 Stuttgart fon: +49 711 747503
Germany
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Re: [HACKERS] thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 08:16 ` Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 15:33 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 17:13 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-09 22:51 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Tom Lane <tgl@sss.pgh.pa.us>
1998-08-10 07:19 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
@ 1998-08-11 07:47 ` Herouth Maoz <herouth@oumail.openu.ac.il>
1 sibling, 0 replies; 27+ messages in thread
From: Herouth Maoz @ 1998-08-11 07:47 UTC (permalink / raw)
To: Edmund Mergl <E.Mergl@bawue.de>; +Cc: pgsql-interfaces
At 19:44 +0300 on 10/8/98, Edmund Mergl wrote:
> I suggest to spend the effort on making libpq thread safe.
> Otherwise we end up with two DBD modules for postgres.
> If you prepare a module, which does not depend on libpq,
> you will have much more effort on keeping it up to date.
> The main goal of an interface like libpq is to avoid such
> dependencies.
On the other hand, making a DBD module which is not dependent on libpq will
make it possible to use the perl interface on platforms other than UNIX
(e.g. Win, Mac).
So, if potential users have any say on the matter, I'd ask that interfaces
for various cross-platform languages be kept as platform-independent (that
is, as free of native code) as possible.
Herouth
--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg
@ 1998-08-11 10:57 James Oden <joden@lee.k12.nc.us>
1998-08-11 13:02 ` Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg Herouth Maoz <herouth@oumail.openu.ac.il>
0 siblings, 1 reply; 27+ messages in thread
From: James Oden @ 1998-08-11 10:57 UTC (permalink / raw)
To: Herouth Maoz <herouth@oumail.openu.ac.il>; pgsql-interfaces
>At 19:44 +0300 on 10/8/98, Edmund Mergl wrote:
>
>
>> I suggest to spend the effort on making libpq thread safe.
>> Otherwise we end up with two DBD modules for postgres.
>> If you prepare a module, which does not depend on libpq,
>> you will have much more effort on keeping it up to date.
>> The main goal of an interface like libpq is to avoid such
>> dependencies.
>
>On the other hand, making a DBD module which is not dependent on libpq will
>make it possible to use the perl interface on platforms other than UNIX
>(e.g. Win, Mac).
Actually, that is not completely the case. libpq itself has been ported to
a Win32 environment as far as I know, and besides that there is no reason
that it couldn't be, and thus make the Perl DBD module portable. For
porting purposes on Win 95/NT there is Cygnus's GNU/Win 32 stuff which seems
to work pretty well, even in the area of sockets (*yes you can even do
sockets on a Win 95 machine without having to know the WinSock API).
On Macintosh, I'm not sure. I can't think of any reason why libpq could be
ported to the Mac environment. Its only a C interface, though, probably a
lot of code would have to be changed to support Mac's network api (I feel
real unsure here. I have never written any code for a Mac, except in
WordBasic [there's a language I don't put on my résumé]). Also, the GNU
compilers have been ported to the Mac (though, I am unsure of their
usefullness there yet) so that's another possibility in helping to port
libpq.
Anyway, the point I am making is that probably it would be better to have
one API that all of your code is dependent upon under the hood to talk to
the PostgreSQL backend. If libpq isn't ready for that, it probably ought to
be made that way. Otherwise the developers will end up with a lot of
completely independent source trees to maintain, which translates into a
support nightmare...james
>
>So, if potential users have any say on the matter, I'd ask that interfaces
>for various cross-platform languages be kept as platform-independent (that
>is, as free of native code) as possible.
In that case you want them to stay as close to POSIX in the libpq code as
possible, and leverage the POSIX subsystems on most OS's today (OS/400 for
the AS/400 even has a POSIX subsystem, and so does Open VMS). I havn't
looked closely at the code for libpq, but I have assumed up to know that
probably the developers of it stuck as best they could to POSIX just because
this product tends to get ported everywhere.
Shalom...james
^ permalink raw reply [nested|flat] 27+ messages in thread
* Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg
1998-08-11 10:57 Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg James Oden <joden@lee.k12.nc.us>
@ 1998-08-11 13:02 ` Herouth Maoz <herouth@oumail.openu.ac.il>
0 siblings, 0 replies; 27+ messages in thread
From: Herouth Maoz @ 1998-08-11 13:02 UTC (permalink / raw)
To: James Oden <joden@lee.k12.nc.us>; pgsql-interfaces
At 13:57 +0300 on 11/8/98, James Oden wrote:
> On Macintosh, I'm not sure. I can't think of any reason why libpq could be
> ported to the Mac environment. Its only a C interface, though, probably a
> lot of code would have to be changed to support Mac's network api (I feel
> real unsure here. I have never written any code for a Mac, except in
> WordBasic [there's a language I don't put on my résumé]). Also, the GNU
> compilers have been ported to the Mac (though, I am unsure of their
> usefullness there yet) so that's another possibility in helping to port
> libpq.
>
> Anyway, the point I am making is that probably it would be better to have
> one API that all of your code is dependent upon under the hood to talk to
> the PostgreSQL backend. If libpq isn't ready for that, it probably ought to
> be made that way. Otherwise the developers will end up with a lot of
> completely independent source trees to maintain, which translates into a
> support nightmare...james
There is no port of libpq for the Mac. It is much more complicated than you
think. First, Mac programmers don't use malloc. The MacOS has its own
memory manager and you use "handles" (system-created double pointers).
Then, shared libraries depend (if I'm not mistaken) on the code-fragment
manager, which exists on PPC machines, and has many problems on 68k
machines. In short, nobody has done it so far, and it is far from being a
"change all socket calls to their mac equivalent and say AbraKadabra".
Now imagine one of the less commonly used systems - like, say, BeOS. You
have to have a BeOS maven to port libpq there.
Hey, but that's exactly why cross-platform languages have been invented.
The principle is quite simple: An OS guru ports the language ONCE, and
then, anybody who knows the language (and many, many people know perl, TCL
etc), can write the Postgres port to that language.
I mean, what are the chances of finding someone who both understands the
Postgres protocol *and* the MacOS? But a perl port for the MacOS already
exists. So, what are the chances of finding someone who knows both the
Postgres protocol and perl? Much higher, wouldn't you say?
It wouldn't save too much time in updating the source tree, either. A
change of protocol would require updating all the available ports of libpq,
instead of the available ports for the existing languages. I don't see much
improvement here. Moreover, a situation like the ODBC port could arise
again - the old maintainer is no longer available, and a new one is
required to step in. The odds of finding a MacOS/BeOS/whatever guru *twice*
are pretty close to zilch. But a maintainer for the common languages can be
found much more easily - if only because each of the various languages have
a much wider audience than the esoteric OS's.
POSIX, I'm sorry to say, is totally useless.
Herouth
--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma
^ permalink raw reply [nested|flat] 27+ messages in thread
end of thread, other threads:[~1998-08-12 14:48 UTC | newest]
Thread overview: 27+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1998-08-07 18:19 thread-safe libpq and DBD::Pg Goran Thyni <goran@bildbasen.se>
1998-08-08 18:30 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 00:51 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 03:12 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-08-09 03:50 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-08-09 15:49 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 17:34 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-08-09 23:01 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 23:35 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-08-09 08:16 ` Goran Thyni <goran@bildbasen.se>
1998-08-09 15:33 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-08-09 17:13 ` Goran Thyni <goran@bildbasen.se>
1998-08-09 22:51 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-08-10 07:19 ` Goran Thyni <goran@bildbasen.se>
1998-08-10 16:44 ` Edmund Mergl <E.Mergl@bawue.de>
1998-08-11 12:22 ` Goran Thyni <goran@bildbasen.se>
1998-08-11 14:51 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-08-11 16:50 ` Hannu Krosing <hannu@trust.ee>
1998-08-11 13:13 ` JohnDz <John_dzilvelis@valpak.com>
1998-08-12 14:29 ` Eric Marsden <emarsden@mail.dotcom.fr>
1998-08-12 14:48 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-08-12 14:04 ` Eric Marsden <emarsden@mail.dotcom.fr>
1998-08-12 14:33 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-08-12 06:03 ` Edmund Mergl <E.Mergl@bawue.de>
1998-08-11 07:47 ` Herouth Maoz <herouth@oumail.openu.ac.il>
1998-08-11 10:57 Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg James Oden <joden@lee.k12.nc.us>
1998-08-11 13:02 ` Herouth Maoz <herouth@oumail.openu.ac.il>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox