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
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
