<?xml version="1.0" encoding="ISO-8859-1"?><document><header><title>Frequently Asked Questions</title></header><body><section id="Questions"><title>Questions</title><section id="proj"><title>1. Project Questions</title><section id="faq-N1000B"><title>1.1. 
    Why are there so many packages?
   </title><p>
    pg/python has many projects. Each are segregated into their own logical
    area. This is done to provide a clear distinction so that use of individual
    packages can be made without binding it to another.
    This allows other projects to conveniently depend on single packages, and
    allows package maintainers to construct the installation and update plan
    based on the individual packages.
   </p></section><section id="faq-N10014"><title>1.2. 
    Why are code names used so frequently?
   </title><p>
    Use of code names help to establish a major version of a project. For
    instance, one backend implementation is TEOP. If the project were to steer
    in a substantially different direction, a new code name would be appointed
    instead of clobbering the current practices.
    This allows for more natural version traversal.
   </p></section><section id="faq-N1001D"><title>1.3. 
    How can I help out?
   </title><p>
    Experiment, patch, feedback. Just dive into the code. Give feedback, write
    patches, and experiment with it. If you know Python, the frontend and
    typical areas shouldn't be too difficult. However, the backend is a
    different story as it deals with both the PostgreSQL and Python C APIs.
    There is no easy entrance here.
   </p></section></section><section id="ip"><title>2. Interface Protocol</title><section id="faq-N1002D"><title>2.1. 
    What's Green Trunk?
   </title><p>
    Green Trunk is the code name of an interface protocol, a Python API
    specification. It formally specifies the expected features of a conforming
    interface. See the Interface Protocol project for more information.
   </p></section><section id="faq-N10036"><title>2.2. 
    Why not use the DB-API 2.0 standard?
   </title><p>
    DB-API 2.0 specifies a decent interface, but it fails to provide a very
    Pythonic interface for PostgreSQL. The Interface Protocol attempts to create
    a Python interface that objectifies PostgreSQL elements, something that
    DB-API could not have done due to its broader application. Nonetheless,
    it is likely that all interface implementations will include DB-API 2.0
    layers.
   </p></section></section><section id="fe"><title>3. Frontend</title><section id="faq-N10046"><title>3.1. 
    What's Proboscis?
   </title><p>
    Proboscis is the code name of the frontend implementation. See the project
    page for more information.
   </p></section><section id="faq-N1004F"><title>3.2. 
    Why yet another %$#%@#@ driver?
   </title><p>
    Firstly, watch yer language. Secondly, the answer is flexibility. No other
    driver provides the level of flexibility that PQueue and Proboscis do.
    Proboscis can work over an arbitrary data stream(pipe keyword), and may be
    useable in systems like the Twisted framework without using threads.
   </p></section><section id="faq-N10058"><title>3.3. 
    How slow is it?
   </title><p>
    The primary bottleneck on cursor fetches is the local typing(parsing or
    reading the individual object data and creating the Python object to
    represent it). This means that the protocol parts of the system are not a
    substantial impediment on performance. It should be able to reach speeds
    close to the libpq wrappers.
   </p></section></section><section id="be"><title>4. Backend</title><section id="faq-N10068"><title>4.1. 
    What's TEOP?
   </title><p>
    TEOP is the code name of the backend interface. It is an acronym and stands
    for The Elusive Ophidian Proboscidea.
   </p></section><section id="faq-N10071"><title>4.2. 
    Why do I get this pthread symbol not found error?
   </title><p>
    On FreeBSD, PostgreSQL needs to be compiled against libc_r, in 4.x, or
    libpthread, in 5.x to work with Python. You either need to recompile
    PostgreSQL against the appropriate library, or execute PostgreSQL with the
    LD_PRELOAD environment variable set to the path of the appropriate threading
    library stated earlier(/usr/lib/libc_r.so or /usr/lib/libpthread.so).
   </p></section></section></section></body></document><!--
 ! vim: ts=1:sw=1:et:
 !-->