Thread

  1. Oid Questions

    Michael J. Rogan <mrogan@fpelectronics.com> — 1998-01-22T16:11:14Z

    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 *
    
    
  2. new DEV FAQ

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-01-22T20:05:37Z

    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
    
    
  3. Re: [HACKERS] Oid Questions

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-01-22T21:25:19Z

    > 
    > 
    > 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
    
    
  4. Re: [HACKERS] Oid Questions

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-01-22T22:09:00Z

    > 
    > 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
    
    
  5. Re: [HACKERS] Oid Questions

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-01-22T22:34:51Z

    > 
    > 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
    
    
  6. Re: [HACKERS] Oid Questions

    Zeev Suraski <bourbon@netvision.net.il> — 1998-01-22T23:55:35Z

    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
    
    
  7. Re: [HACKERS] Oid Questions

    Zeev Suraski <bourbon@netvision.net.il> — 1998-01-23T00:33:09Z

    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