Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] thread-safe libpq and DBD::Pg

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane)
Cc: goran(at)bildbasen(dot)se, pgsql-interfaces(at)postgreSQL(dot)org, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] thread-safe libpq and DBD::Pg
Date: 1998-08-09 03:50:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-interfaces
> 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

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(at)candle(dot)pha(dot)pa(dot)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)

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1998-08-09 04:49:48
Subject: pgindent and prototypes
Previous:From: Bruce MomjianDate: 1998-08-09 03:12:09
Subject: Re: [HACKERS] thread-safe libpq and DBD::Pg

pgsql-interfaces by date

Next:From: Goran ThyniDate: 1998-08-09 08:16:36
Subject: Re: thread-safe libpq and DBD::Pg
Previous:From: Bruce MomjianDate: 1998-08-09 03:12:09
Subject: Re: [HACKERS] thread-safe libpq and DBD::Pg

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group