★ wanayoo — archive 1999 http://www.php.net/manual/fr/function.pg-exec.phpNouvelle recherche | Portail wanayoo

PHP Home Page

Manual Table of Contents
Up to PostgreSQL
Quick Reference
PostgreSQL
English version of this pageGerman version of this pageJapanese version of this page
Italian version of this pageFrench version of this pageHungarian version of this page
Spanish version of this pageDutch version of this page
* pg_Close
* pg_cmdTuples
* pg_Connect
* pg_DBname
* pg_ErrorMessage
* pg_Exec
* pg_Fetch_Array
* pg_Fetch_Object
* pg_Fetch_Row
* pg_FieldIsNull
* pg_FieldName
* pg_FieldNum
* pg_FieldPrtLen
* pg_FieldSize
* pg_FieldType
* pg_FreeResult
* pg_GetLastOid
* pg_Host
* pg_loclose
* pg_locreate
* pg_loopen
* pg_loread
* pg_loreadall
* pg_lounlink
* pg_lowrite
* pg_NumFields
* pg_NumRows
* pg_Options
* pg_pConnect
* pg_Port
* pg_Result
* pg_tty

  Thanks to:
 Chek.com
 easyDNS
 VA Linux Systems

  Related sites:
Apache
MySQL
PostgreSQL
Zend Tech.

  Community:
LinuxFund.org
OSDN
Manual: pg_Exec
View the source code for this pageSearch the site



Previous page
 pg_ErrorMessage
 Updated
Thu, 09 Nov 2000
pg_Fetch_Array 
Next page


pg_Exec

(PHP 3, PHP 4 )

pg_Exec -- Exécute une requête.

Description

int pg_exec (int connection, string query)

Retourne un index de résultat, si la requête a été correctement exécutée, et FALSE en cas d'échec, ou si la connexion connection n'était pas un index de connexion valide. En cas d'erreur, le message d'erreur peut être obtenu grâce à la fonction pg_ErrorMessage(), si l'index de connexion était valide. Envoie une requête à un serveur PostgreSQL identifié grâce à l'index de connexion. La réponse retournée par cette fonction est un index de résultat qui devra être utilisé pour accéder aux lignes de résultat, grâce à d'autres fonctions PostgreSQL.

Note: PHP/FI retournait 1 lorsque la requête n'attendait pas de données en réponse (insertion, modifcations, par exemple), et retournait un nombre plus grand que 1, même sur un select qui donnait un ensemble vide. Ce n'est plus le cas.


User Contributed Notes: pg_Exec


bkosse@thecreek.com
19-May-1999 07:54
Make sure that you close any connections you have (or use persistant connections), otherwise your pg_exec() call may fail without any warnings showing up.


jason@familynet.net
10-Dec-1999 01:53
Insert returns an OID. Use the pg_GetLastOid() function to SELECT the last inserted row of your session. To get an automatic serialized id, set up your table like this:

<PRE>
SQL:

CREATE TABLE something (
"itemno" int4 PRIMARY KEY DEFAULT NEXTVAL('serial'),
"name" varchar(80),
);
CREATE SEQUENCE serial INCREMENT 1 START 1;


PHP Example:

$result=pg_exec($conn,"INSERT INTO customer (name) VALUES ('test');");
if(!$result) {
error("Unable to update.");
}
else {
// display
$oid = pg_GetLastOid($result);
if($oid<0) error("bad news");
$result=pg_exec($conn,"SELECT itemno FROM customer WHERE oid = $oid;");
if(!$result) error("worse news");
$arr = pg_fetch_array ($result, 0);
echo "

ItemNo: $arr[0]

";
}
</PRE>



bradleytsi@aol.com
19-Jan-2000 12:02
Also, here is a web site that should help you out:
http://w3.one.net/~jhoffman/sqltut.htm



knight@novell.ohsh.u-szeged.hu
21-Jan-2000 05:05
I suppose pg_GetLastOid() returns a zero value when you want to insert a duplicate key. So checking should be the following:
<pre>if (!pg_GetLastOid($result) ||
(pg_GetLastOid($result) < 0)) {
code_on_error
else {
code_on_success
}
</pre>



jeff@pgsql.com
13-Aug-2000 10:11
few note/tips for everyone out there

1: that getlast oid or whatever it's called. that's slow and painful.. try this.

if your table (ie "users" has a serial type (ie "uid") and you want to find out the most recent one. do this select
SELECT currval('id_users_seq');

2nd tip to see if a INSERT/UPDATE worked
or not and how to suppress it's error message

1: $insert=@pg_exec($dbh,$insertstring)
if ($insert == 0 ) { /* it screwed up */ }

2: the @ infron of pg_exec suppresses the errors.

jeff@pgsql.com



ronabop@php.net
17-Aug-2000 05:04
On pg_getlastoid vs. SELECT currval('some_table_seq');
One or the other may work better, depending on usage. Currval() has a recovery problem, however. If two users hit a database at close to the same time, _after_ an insert (say, 2-10 milliseconds of eachother), they may both get the same currval, as the web front-end is running as one user (or, more usually, several of them, so this is rare, but theoretically possible).

This means that they *may* not get the right value for the last serial number, unless youir lookup is performed on something returned from the last statement (such as an OID). It's not a bug, or a race condition, it's *expected behavior* that it wouldn't give an old number after the web process asked for a new number.

There is a similar issue with nextval(). If two users get one at similar times, but one abandons the session/pageload/whatever, you can wind up with holes in the serial numbers. Set up two windows with the following script, and reload on a few times.... and watch your serial sequence gain holes.
<?
$conn = pg_connect("dbname=common");
$result=pg_exec($conn,"SELECT nextval('contact_seq');");
echo pg_result($result,0,nextval);
?>

Hence, pg_getlastoid.



brooke@jump.net
22-Oct-2000 12:49
A lot of people have griped about getLastOid vs. other methods. Here's the real deal:

One of the many greatnesses of Postgres is Declarative Referential Integrity, available in versions with major number 7 and up. Unfortunately in the beta versions I tried, you could not declare referential integrity against the oid attribute of a table. Therefore, you had to use an explicit "id" field. You could use a serial type (ie default value=nextval(series)) but then if you want the generated ID, you have to do a table lookup to find it. The right way to do it is to explicitly read nextval(sequence) and use it. If somebody gives you holes in your sequence, that's totally OK and a fact of life. It's the only tradeoff which is both fast and correct.



 About Notes


Previous page
 pg_ErrorMessage
 Updated
Thu, 09 Nov 2000
pg_Fetch_Array 
Next page





Who's responsible for this?
Top of this page

Site
Hosting:



Located in
United States
Elements of this website are subject to copyright.
Questions about installing or using PHP should be directed to one of the mailing lists.
Only questions about the website should be directed to webmaster@php.net.