#87 db_pgsql.inc: lock() causes a warning

[Marco Pratesi]

With the PostgreSQL class, the following code causes a
warning:

$qid = new DB_Sql();
$qid->lock("tablename");

The warning is:

Warning: Supplied argument is not a valid PostgreSQL
link resource...

This is due to the fact that in this case the
constructor issues
an empty query, that causes a "return 0" without issuing
"$this-connect()".
When lock() is requested, the following line is executed:

$result = pg_Exec($this->Link_ID, "lock table $table");

but $this->Link_ID is not a valid link, as connect()
has not been
executed yet.
The problem could be solved using $this->query() instead of
pg_Exec(), in analogy to what is done in db_mysql.inc,
as in the following:

$result = $this->query("lock table $table");

[Anonymous]

Logged In: YES
user_id=279065

I thought one of our fearless programmers had gone
through the db_* classes and made them more uniform?
Or was a I dreaming?

..chris

[Richard Archer]

Logged In: YES
user_id=279311

I did a lot of work on some of the db classes (MySQL, OCI8,
ODBC come to mind). But I don't have most of those other
databases running to test with. I think you'll find most of
my work is in the devel tree only. I wasn't willing to
commit untested code to the -stable tree.

For example, the odbc driver in devel has *heaps* of
improvements and bug fixes. It even implements lock(). While
I did have an ODBC datasource at the time, I wasn't willing
to commit a 500 line patch to -stable based on my
development testing alone.

Maybe we should just bite the bullet and commit this stuff
to -stable and then fix any problems which arise.

[nathan hruby]

Logged In: YES
user_id=19736

> Maybe we should just bite the bullet and commit this stuff
> to -stable and then fix any problems which arise.

Yes please :)

That's what the -pre's are for.. to suss out the bugs by the
advertursome and intelligent users before releasing to the
masses.

[Anonymous]

Logged In: YES
user_id=279065

I say go for it.

I think getting a packaged pre-release out the door is
more important at this point in time than trying to scare
up the people and resources to do that kind of coverage
testing.

..chris

[Marco Pratesi]

Logged In: YES
user_id=65709

I agree.
I am working on the new development branch of PgMarket
and I could be useful just with testing the MySQL and PgSQL
classes.
I am using the MySQL class taken from 7.4pre1, but, if that
class is too much outdated w.r.t. the CVS, my tests are not
as much useful as they could be.

I am also using the PgSQL class (and I develop mainly
using PostgreSQL rather than MySQL); to solve some problems
I have switched to a CVS snapshot of the PgSQL class + some
changes made by me, that fix some minor problems:

function unlock() {
- return pg_Exec($this->Link_ID, "commit");
+ return $this->query("commit");
}

I have made this change for coherence with the lock() method,
where I have also eliminated an "else" to simplify the code:

function lock($table, $mode = "write") {
if ($mode == "write") {
- $result = pg_Exec($this->Link_ID, "lock table $table");
- } else {
- $result = 1;
+ return $this->query("lock table $table");
}
- return $result;
+ return 1;
}

Moreover, I have made the following changes to avoid
the possibility of warnings with error_reporting = E_ALL :

function f($Name) {
- return $this->Record[$Name];
+ if (isset($this->Record[$Name])) {
+ return $this->Record[$Name];
+ }
}

function p($Name) {
- print $this->Record[$Name];
+ if (isset($this->Record[$Name])) {
+ print $this->Record[$Name];
+ }
}

BTW, if I can be helpful for the PHPLib classes I am using,
I am happy to help.
I am also developing some new PHP classes
that are compatible also with PHP3 and that I release
under the GNU LGPL.

Bye,

Marco Pratesi