> I wouldn't call pgsql support in PHP stone age :)
Hmmm, you're obviously not a PostgreSQL developer, and been wondering
why 2 year old postgresql technology hasn't been supported yet :D
> I do think that this would be a very nice addition to php 5.1.
>
> A few questions:
>
> Why do we need pg_query_params. Isn't prepare/execute enough?
It's a 1-1 mapping of the libpq PostgreSQL API. Basically it allows you
to avoid sql injection attacks and quoting, and also not have to worry
about having to prepare/execute a named prepared query that, as you
mention below, might collide with a previous one. I chose to emulate
the wisdom of the libpq API designers on this one.
Check here:
http://www.postgresql.org/docs/current/static/libpq-exec.html
> pg_execute($conn, $stmt, $params) seem to be already taking care of the
> parameters passed. (btw. I wouldn't make $conn optional, it makes adding
> additional parameters later on pain).
I made it optional simply to match the other postgresql functions,
specifically pg_query. It's easy enough to change if you like.
> How does this work over persistent connections? AFAIK trying to prepare a
> statment with the same name on the same connection will result in an error.
Correct, but that's exactly the same as executing a PREPARE command via
SQL instead of via the v3 protocol. (Which people have been doing for
years.)
PostgreSQL currently lacks adequate commands for properly resetting
persistent connections :( For instance, prepared queries and named open
cursors will persist across persistent connections in PHP - but that's
not new.
Chris
