Обсуждение: new DEV FAQ
Developers Frequently Asked Questions (FAQ) for PostgreSQL Last updated: Thu Jan 22 15:04:10 EST 1998 Current maintainer: Bruce Momjian (maillist@candle.pha.pa.us) The most recent version of this document can be viewed at the postgreSQL Web site, http://postgreSQL.org. ------------------------------------------------------------------------ Questions answered: 1) General questions 1) What tools are available for developers? 2) What books are good for developers? 3) Why do we use palloc() and pfree() to allocate memory? 4) Why do we use Node() and List() to make data structures? ------------------------------------------------------------------------ 1) What tools are available for developers? Aside from the User documentation mentioned in the regular FAQ, there are several development tools available. First, all the files in the /tools directory are designed for developers. RELEASE_CHANGES changes we have to make for each release SQL_keywords standard SQL'92 keywords backend web flowchart of the backend directories ccsym find standard defines made by your compiler entab converts tabs to spaces, used by pgindent find_static finds functions that could be made static find_typedef get a list of typedefs in the source code make_ctags make vi 'tags' file in each directory make_diff make *.orig and diffs of source make_etags make emacs 'etags' files make_keywords.README make comparison of our keywords and SQL'92 make_mkid make mkid ID files mkldexport create AIX exports file pgindent indents C source files Let me note some of these. If you point your browser at the tools/backend directory, you will see all the backend components in a flow chart. You can click on any one to see a description. If you then click on the directory name, you will be taken to the source directory, to browse the actual source code behind it. We also have several README files in some source directories to describe the function of the module. The browser will display these when you enter the directory also. The tools/backend directory is also contained on our web page under the title Backend Flowchart. Second, you really should have an editor that can handle tags, so you can tag a function call to see the function definition, and then tag inside that function to see an even lower-level function, and then back out twice to return to the original function. Most editors support this via tags or etags files. Third, you need to get mkid from ftp.postgresql.org. By running tools/make_mkid, an archive of source symbols can be created that can be rapidly queried like grep or edited. make_diff has tools to create patch diff files that can be applied to the distribution. pgindent will format source files to match our standard format, which has four-space tabs, and an indenting format specified by flags to the your operating system's utility indent. 2) What books are good for developers? I have two good books, An Introduction to Database Systems, by C.J. Date, Addison, Wesley and A Guide to the SQL Standard, by C.J. Date, et. al, Addison, Wesley. 3) Why do we use palloc() and pfree() to allocate memory? palloc() and pfree() are used in place of malloc() and free() because we automatically free all memory allocated when a transaction completes. This makes it easier to make sure we free memory that gets allocated in one place, but only freed much later. There are several contexts that memory can be allocated in, and this controls when the allocated memory is automatically freed by the backend. 4) Why do we use Node() and List() to make data structures? We do this because this allows a consistent way to pass data inside the backend in a flexible way. Every node has a NodeTag which specifies what type of data is inside the Node. Lists are lists of Nodes. lfirst(), lnext(), and foreach() are used to get, skip, and traverse throught Lists. -- Bruce Momjian maillist@candle.pha.pa.us
Hello. Zeev Suraski <zeev@php.net> is making some changes to the PostgreSQL code in PHP3 so that the Oid is returned in the pg_exec funtion if it is an insert. What is the size of the Oid (unsigned, signed etc) and will it ever be zero. Michael * Michael J. Rogan, Network Administrator, 905-624-3020 * * Mark IV Industries, F-P Electronics & I.V.H.S. Divisions * * mrogan@fpelectronics.com mrogan@ivhs.com *
>
>
> Hello.
>
> Zeev Suraski <zeev@php.net> is making some changes to the PostgreSQL code
> in PHP3 so that the Oid is returned in the pg_exec funtion if it is an
> insert.
>
> What is the size of the Oid (unsigned, signed etc) and will it ever be
> zero.
typedef unsigned int Oid;
A zero value for OID is reserved for an Invalid OID. If it returns a
zero, I would pass it back to the application. You may want to call
libpq's PQoidStatus() to get this information. That is a new function
for 6.2.1.
--
Bruce Momjian
maillist@candle.pha.pa.us
At 16:25 22/01/98 -0500, Bruce Momjian wrote: >A zero value for OID is reserved for an Invalid OID. If it returns a >zero, I would pass it back to the application. You may want to call >libpq's PQoidStatus() to get this information. That is a new function >for 6.2.1. Ok, please tell me if this logic is correct. It describes the logic behind the implementation of pg_exec() in PHP. First, the query is executed. If the status is PGRES_EMPTY_QUERY or PGRES_BAD_RESPONSE or PGRES_NONFATAL_ERROR or PGRES_FATAL_ERROR, return FALSE (failure). If it returns PGRES_COMMAND_OK (which is, from what I understand, a successful query that is, by definition, not supposed to return rows) - check PQoidStatus(). If it's not null, atoi() of it is not 0, return its return value as a numeric integer. If it is zero, assume that this was a successful query that didn't cause the oid to be updated, and return TRUE (successful query that does not return rows or oid). Otherwise, assume that that was a succesful query that returned rows - return a PostgresSQL result identifier. I guess that my key question is, whether or not it's correct to assume PGRES_COMMAND_OK + PQoidStatus() == 0 or "0" => successful query that did not return rows and did not update the oid, OR, is it possible that PQoidStatus() of zero reflects some error, even though the return value was PGRES_COMMAND_OK? PHP can return different datatypes from the same function, in case you were wondering :) Zeev --- Zeev Suraski <zeev@php.net> Web programmer, System administrator, Netvision LTD http://bourbon.netvision.net.il/ ICQ: 1450980 For a PGP public key, finger bourbon@netvision.net.il
> > At 16:25 22/01/98 -0500, Bruce Momjian wrote: > >A zero value for OID is reserved for an Invalid OID. If it returns a > >zero, I would pass it back to the application. You may want to call > >libpq's PQoidStatus() to get this information. That is a new function > >for 6.2.1. > > Ok, please tell me if this logic is correct. It describes the logic behind > the implementation of pg_exec() in PHP. > > First, the query is executed. If the status is PGRES_EMPTY_QUERY or > PGRES_BAD_RESPONSE or PGRES_NONFATAL_ERROR or PGRES_FATAL_ERROR, return > FALSE (failure). > If it returns PGRES_COMMAND_OK (which is, from what I understand, a > successful query that is, by definition, not supposed to return rows) - > check PQoidStatus(). If it's not null, atoi() of it is not 0, return its > return value as a numeric integer. If it is zero, assume that this was a > successful query that didn't cause the oid to be updated, and return TRUE > (successful query that does not return rows or oid). > Otherwise, assume that that was a succesful query that returned rows - > return a PostgresSQL result identifier. Sorry, got lost in this paragraph. > > I guess that my key question is, whether or not it's correct to assume > PGRES_COMMAND_OK + PQoidStatus() == 0 or "0" => successful query that did > not return rows and did not update the oid, OR, is it possible that > PQoidStatus() of zero reflects some error, even though the return value was > PGRES_COMMAND_OK? It is the result status, PGRES_COMMAND_OK that is important. The PQoidStatus() is really there just as an aid. Only an INSERT returns an OID as part of the result string. We use this function to just pull it out of the string. If they do a SELECT ... INTO, they are inserting zero or multiple OIDs, so this value is the last oid inserted. We also have new in 6.2.1 PQcmdTuples(), which shows how many rows were affected by the INSERT, UPDATE, or DELETE. Again, it comes out of the string returned in the Result structure. See libpq/fe-exec.c for the source to both of these. > > PHP can return different datatypes from the same function, in case you were > wondering :) Yep, I remember. -- Bruce Momjian maillist@candle.pha.pa.us
I'll try to rephrase the question without taking 3 complex paragraphs to do that :) Is there a way to know a PostgresSQL result holds NO interesting information (no rows, no oids, no nothing)? The more I think of it, the more it seems like this isn't the case with PostgresSQL. Moreover, it seems like in most cases the result holds one interesting tidbit of information or another. When I wrote the MySQL module, basically, I made any query that did not return rows (not including select's that returned 0 rows) but succeeded return TRUE instead of a result handler, since there wasn't much point at keeping that result. With MySQL the information about the last inserted id (mysql_insert_it(), I think it's comparable to the last oid in pgsql) and the number of affected rows can be obtained from the 'server' structure, and not the restul structure as it is with Postgres. I guess I'll change the Postgres module to always keep the result structures and return result identifiers on a successful query. Zeev --- Zeev Suraski <zeev@php.net> Web programmer, System administrator, Netvision LTD http://bourbon.netvision.net.il/ ICQ: 1450980 For a PGP public key, finger bourbon@netvision.net.il
> > I'll try to rephrase the question without taking 3 complex paragraphs to do > that :) > > Is there a way to know a PostgresSQL result holds NO interesting > information (no rows, no oids, no nothing)? > > The more I think of it, the more it seems like this isn't the case with > PostgresSQL. Moreover, it seems like in most cases the result holds one > interesting tidbit of information or another. When I wrote the MySQL > module, basically, I made any query that did not return rows (not including > select's that returned 0 rows) but succeeded return TRUE instead of a > result handler, since there wasn't much point at keeping that result. With > MySQL the information about the last inserted id (mysql_insert_it(), I > think it's comparable to the last oid in pgsql) and the number of affected > rows can be obtained from the 'server' structure, and not the restul > structure as it is with Postgres. > > I guess I'll change the Postgres module to always keep the result > structures and return result identifiers on a successful query. Yes, all the return information for results that return zero rows are in the Result structure, so you can have multiple results open at the same time, and query them separately. They remain valid until PQclear()'ed. -- Bruce Momjian maillist@candle.pha.pa.us