diff --git a/Book/index.rst b/Book/index.rst
index 75d8eb53..992f1bcd 100644
--- a/Book/index.rst
+++ b/Book/index.rst
@@ -11,6 +11,7 @@ PHP 7
     php7/build_system.rst
     php7/internal_types.rst
     php7/extensions_design.rst
+    php7/pdo.rst
     php7/memory_management.rst
     php7/zend_engine.rst
     php7/debugging.rst
diff --git a/Book/php7/pdo.rst b/Book/php7/pdo.rst
new file mode 100644
index 00000000..6c215229
--- /dev/null
+++ b/Book/php7/pdo.rst
@@ -0,0 +1,25 @@
+PDO Driver How-To
+=================
+
+The purpose of this How-To is to provide a basic understanding of the steps
+required to write a database driver that interfaces with the PDO layer.
+Please note that this is still an evolving API and as such, subject to
+change. This document was prepared based on version 0.3 of PDO.
+The learning curve is steep; expect to spend a lot of time on the
+prerequisites.
+
+Contents:
+
+.. toctree::
+    :maxdepth: 2
+
+    pdo/prerequisites.rst
+    pdo/preparation.rst
+    pdo/implementing.rst
+    pdo/building.rst
+    pdo/testing.rst
+    pdo/packaging.rst
+    pdo/pdo-dbh-t.rst
+    pdo/pdo-stmt-t.rst
+    pdo/constants.rst
+    pdo/error-handling.rst
diff --git a/Book/php7/pdo/building.rst b/Book/php7/pdo/building.rst
new file mode 100644
index 00000000..6f9b35fa
--- /dev/null
+++ b/Book/php7/pdo/building.rst
@@ -0,0 +1,31 @@
+Building
+========
+
+The build process is designed to work with PEAR.
+There are two files that are used to assist in configuring your
+package for building. The first is config.m4 which is the
+``autoconf`` configuration file for all platforms except
+Win32. The second is config.w32 which is a build configuration file for use
+on Win32. Skeleton files for these are built for you when you first set up
+your project. You then need to customize them to fit the needs of your
+project.  Once you've customized your config files, you can build your driver
+using the following sequence of commands:
+
+Before first build:
+ 
+.. code-block:: bash
+
+    $ sudo pecl install PDO
+ 
+For each build:
+
+.. code-block:: bash
+
+    $ cd pdo_SKEL
+    $ phpize
+    $ ./configure
+    $ make
+    $ sudo make install
+
+The process can then be repeated as necessary during the development
+process.
diff --git a/Book/php7/pdo/constants.rst b/Book/php7/pdo/constants.rst
new file mode 100644
index 00000000..d4ab8748
--- /dev/null
+++ b/Book/php7/pdo/constants.rst
@@ -0,0 +1,77 @@
+Constants
+=========
+
+.. _pdo_attributes:
+
+Database and Statement Attributes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+PDO_ATTR_AUTOCOMMIT
+    BOOL
+    
+    TRUE if autocommit is set, FALSE otherwise.
+    
+    ``dbh->auto_commit`` contains value. Processed by PDO directly.
+
+PDO_ATTR_PREFETCH
+    LONG
+    
+    Value of the prefetch size in drivers that support it.
+
+PDO_ATTR_TIMEOUT
+    LONG
+
+    How long to wait for a db operation before timing out.
+
+PDO_ATTR_ERRMODE
+    LONG
+
+    Processed and handled by PDO
+
+PDO_ATTR_SERVER_VERSION
+    STRING
+
+    The "human-readable" string representing the
+    Server/Version this driver is currently connected to.
+
+PDO_ATTR_CLIENT_VERSION
+    STRING
+    
+    The "human-readable" string representing the Client/Version this driver supports.
+
+PDO_ATTR_SERVER_INFO
+    STRING
+    
+    The "human-readable" description of the Server.
+
+PDO_ATTR_CONNECTION_STATUS
+    LONG
+    
+    Values not yet defined
+
+PDO_ATTR_CASE
+    LONG
+    
+    Processed and handled by PDO.
+
+PDO_ATTR_CURSOR_NAME
+    STRING
+
+    String representing the name for a database cursor for use in
+    "where current in <name>" SQL statements.
+
+PDO_ATTR_CURSOR
+    LONG
+
+    PDO_CURSOR_FWDONLY
+        Forward only cursor
+    PDO_CURSOR_SCROLL
+        Scrollable cursor
+
+The values for the attributes above are all defined in terms of the Zend
+API. The Zend API contains macros that can be used to convert a ``*zval`` to a
+value. These macros are defined in the Zend header file, zend_API.h in the
+Zend directory of your PHP build directory. Some of these attributes can be
+used with the statement attribute handlers such as the PDO_ATTR_CURSOR and
+PDO_ATTR_CURSOR_NAME. See the statement attribute handling functions for
+more information.
diff --git a/Book/php7/pdo/error-handling.rst b/Book/php7/pdo/error-handling.rst
new file mode 100644
index 00000000..96889e02
--- /dev/null
+++ b/Book/php7/pdo/error-handling.rst
@@ -0,0 +1,39 @@
+.. _pdo_error_handling:
+
+Error handling
+==============
+
+Error handling is implemented using a hand-shaking protocol between 
+PDO and the database driver code. The database driver code
+signals PDO that an error has occurred via a failure
+(``0``) return from any of the interface functions. If a zero
+is returned, set the field ``error_code`` in the control
+block appropriate to the context (either the pdo_dbh_t or pdo_stmt_t block).
+In practice, it is probably a good idea to set the field in both blocks to
+the same value to ensure the correct one is getting used.
+
+The error_mode field is a six-byte field containing a 5 character ASCIIZ
+SQLSTATE identifier code. This code drives the error message process. The
+SQLSTATE code is used to look up an error message in the internal PDO error
+message table (see pdo_sqlstate.c for a list of error codes and their
+messages). If the code is not known to PDO, a default
+"Unknown Message" value will be used.
+
+In addition to the SQLSTATE code and error message, PDO will
+call the driver-specific fetch_err() routine to obtain supplemental data
+for the particular error condition. This routine is passed an array into
+which the driver may place additional information. This array has slot
+positions assigned to particular types of supplemental info:
+
+#.  A native error code. This will frequently be an error code obtained
+    from the database API.
+
+#.  A descriptive string. This string can contain any additional
+    information related to the failure. Database drivers typically include
+    information such as an error message, code location of the failure, and
+    any additional descriptive information the driver developer feels
+    worthy of inclusion. It is generally a good idea to include all
+    diagnostic information obtainable
+    from the database interface at the time of the failure. For
+    driver-detected errors (such as memory allocation problems), the driver
+    developer can define whatever error information that seems appropriate.
diff --git a/Book/php7/pdo/implementing.rst b/Book/php7/pdo/implementing.rst
new file mode 100644
index 00000000..51c92805
--- /dev/null
+++ b/Book/php7/pdo/implementing.rst
@@ -0,0 +1,851 @@
+Fleshing out your skeleton
+==========================
+
+Major Structures and Attributes
+-------------------------------
+
+The major structures, pdo_dbh_t and pdo_stmt_t are defined and explained in
+:ref:`pdo_dbh_t` and :ref:`pdo_stmt_t` respectively. Database and Statement attributes are
+defined in :ref:`pdo_attributes`. Error handling is explained in  :ref:`pdo_error_handling`.
+
+pdo_SKEL.c: PHP extension glue
+------------------------------
+
+function entries
+^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static function_entry pdo_SKEL_functions[] = {
+        { NULL, NULL, NULL }
+    };
+
+This structure is used to register functions into the global php function
+namespace.  PDO drivers should try to avoid doing this, so it is
+recommended that you leave this structure initialized to NULL, as shown in
+the synopsis above.
+
+Module entry
+^^^^^^^^^^^^
+
+.. code-block:: c
+
+    #if ZEND_EXTENSION_API_NO >= 220050617
+    static zend_module_dep pdo_SKEL_deps[] = {
+        ZEND_MOD_REQUIRED("pdo")
+        {NULL, NULL, NULL}
+    };
+    #endif
+
+    zend_module_entry pdo_SKEL_module_entry = {
+    #if ZEND_EXTENSION_API_NO >= 220050617
+        STANDARD_MODULE_HEADER_EX, NULL,
+        pdo_SKEL_deps,
+    #else
+        STANDARD_MODULE_HEADER,
+    #endif
+        "pdo_SKEL",
+        pdo_SKEL_functions,
+        PHP_MINIT(pdo_SKEL),
+        PHP_MSHUTDOWN(pdo_SKEL),
+        NULL,
+        NULL,
+        PHP_MINFO(pdo_SKEL),
+        PHP_PDO_<DB>_MODULE_VERSION,
+        STANDARD_MODULE_PROPERTIES
+    };
+
+    #ifdef COMPILE_DL_PDO_<DB>
+    ZEND_GET_MODULE(pdo_db)
+    #endif
+
+A structure of type zend_module_entry called
+pdo_SKEL_module_entry must be declared and should include reference to
+the pdo_SKEL_functions table defined previously.
+
+Standard PHP Module Extension Functions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+PHP_MINIT_FUNCTION
+
+.. code-block:: c
+
+    PHP_MINIT_FUNCTION(pdo_SKEL)
+    {
+        return php_pdo_register_driver(&pdo_SKEL_driver);
+    }
+
+This standard PHP extension function should be used to register your
+driver with the PDO layer. This is done by calling the
+``php_pdo_register_driver`` function passing a pointer to
+a structure of type ``pdo_driver_t`` typically named
+``pdo_SKEL_driver``.  A ``pdo_driver_t``
+contains a header that is generated using the
+``PDO_DRIVER_HEADER(SKEL)`` macro and
+``pdo_SKEL_handle_factory`` function pointer. The
+actual function is described during the discussion of the
+``SKEL_dbh.c`` unit.
+
+PHP_MSHUTDOWN_FUNCTION
+
+.. code-block:: c
+
+    PHP_MSHUTDOWN_FUNCTION(pdo_SKEL)
+    {
+        php_pdo_unregister_driver(&pdo_SKEL_driver);
+        return SUCCESS;
+    }
+
+This standard PHP extension function is used to unregister your driver
+from the PDO layer. This is done by calling the
+``php_pdo_unregister_driver`` function, passing the same
+``pdo_SKEL_driver`` structure that was passed in the
+init function above.
+
+PHP_MINFO_FUNCTION
+
+This is again a standard PHP extension function. Its purpose is to
+display information regarding the module when the
+``phpinfo`` is called from a script.  The convention is
+to display the version
+of the module and also what version of the db you are dependent on, along
+with any other configuration style information that might be relevant.
+
+SKEL_driver.c: Driver implementation
+------------------------------------
+
+This unit implements all of the database handling methods that support the
+PDO database handle object. It also contains the error fetching routines.
+All of these functions will typically need to access the global variable
+pool. Therefore, it is necessary to use the Zend macro TSRMLS_DC macro at
+the end of each of these statements. Consult the Zend programmer
+documentation for more information on this macro.
+
+pdo_SKEL_error
+^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static int pdo_SKEL_error(pdo_dbh_t *dbh,
+        pdo_stmt_t *stmt, const char *file, int line TSRMLS_DC)
+
+The purpose of this function is to be used as a generic error handling
+function within the driver. It is called by the driver when an error occurs
+within the driver. If an error occurs that is not related to SQLSTATE, the
+driver should set either ``dbh->error_code`` or
+``stmt->error_code`` to an
+SQLSTATE that most closely matches the error or the generic SQLSTATE error
+"HY000". The file pdo_sqlstate.c in the PDO source contains a table
+of commonly used SQLSTATE codes that the PDO code explicitly recognizes.
+This setting of the error code should be done prior to calling this
+function.; This function should set the global
+``pdo_err`` variable to the error found in either the
+dbh or the stmt (if the variable stmt is not NULL).
+
+dbh
+    Pointer to the database handle initialized by the handle factory
+stmt
+    Pointer to the current statement or NULL. If NULL, the error is derived by error code found in the dbh.
+file
+    The source file where the error occurred or NULL if not available.
+line
+    The line number within the source file if available.
+
+If the dbh member is NULL (which implies that the error is being
+raised from within the PDO constructor), this function should call the
+zend_throw_exception_ex() function otherwise it should return the error
+code.  This function is usually called using a helper macro that customizes
+the calling sequence for either database handling errors or statement
+handling errors.
+
+Example macros for invoking pdo_SKEL_error
+
+.. code-block:: c
+
+    #define pdo_SKEL_drv_error(what) \
+        pdo_SKEL_error(dbh, NULL, what, __FILE__, __LINE__ TSRMLS_CC)
+    #define pdo_SKEL_drv_error(what) \
+        pdo_SKEL_error(dbh, NULL, what, __FILE__, __LINE__ TSRMLS_CC)
+
+For more info on error handling, see :ref:`pdo_error_handling`.
+
+.. note:: Despite being documented here, the PDO driver interface does not specify
+          that this function be present; it is merely a convenient way to handle
+          errors, and it just happens to be equally convenient for the majority of
+          database client library APIs to structure your driver implementation in
+          this way.
+
+pdo_SKEL_fetch_error_func
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static int pdo_SKEL_fetch_error_func(pdo_dbh_t *dbh, pdo_stmt_t *stmt,
+        zval *info TSRMLS_DC)
+
+The purpose of this function is to obtain additional information about the
+last error that was triggered.  This includes the driver specific error
+code and a human readable string.  It may also include additional
+information if appropriate.  This function is called as a result of the PHP
+script calling the ``PDO::errorInfo`` method.
+
+dbh
+    Pointer to the database handle initialized by the handle factory
+stmt
+    Pointer to the most current statement or NULL. If NULL, the error
+    translated is derived by error code found in the dbh.
+info
+    A hash table containing error codes and messages.
+
+The error_func should return two pieces of information as successive array
+elements. The first item is expected to be a numeric error code, the second
+item is a descriptive string. The best way to set this item is by using
+add_next_index.  Note that the type of the first argument need not be
+``long``; use whichever type most closely matches the error code
+returned by the underlying database API.
+
+.. code-block:: c
+
+    /* now add the error information. */
+    /* These need to be added in a specific order */
+    add_next_index_long(info, error_code);   /* driver specific error code */
+    add_next_index_string(info, message, 0); /* readable error message */
+
+This function should return 1 if information is available, 0 if the driver
+does not have additional info.
+
+SKEL_handle_closer
+^^^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static int SKEL_handle_closer(pdo_dbh_t *dbh TSRMLS_DC)
+
+This function will be called by PDO to close an open
+database.
+
+dbh
+    Pointer to the database handle initialized by the handle factory
+
+This should do whatever database specific activity that needs to be
+accomplished to close the open database. PDO ignores the return
+value from this function.
+
+.. _pdo_preparer:
+
+SKEL_handle_preparer
+^^^^^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static int SKEL_handle_preparer(pdo_dbh_t *dbh, const char *sql,
+        long sql_len, pdo_stmt_t *stmt, zval *driver_options TSRMLS_DC)
+
+This function will be called by PDO in response to
+``PDO::query`` and ``PDO::prepare``
+calls from the PHP script.  The purpose of the function is to prepare
+raw SQL for execution, storing whatever state is appropriate into the
+``stmt`` that is passed in.
+
+dbh
+    Pointer to the database handle initialized by the handle factory
+sql
+    Pointer to a character string containing the SQL statement to be prepared.
+sql_len
+    The length of the SQL statement.
+stmt
+    Pointer to the returned statement or NULL if an error occurs.
+driver_options
+    Any driver specific/defined options.
+
+This function is essentially the constructor for a stmt object. This
+function is responsible for processing statement options, and setting
+driver-specific option fields in the pdo_stmt_t structure.
+
+PDO does not process any statement options on the driver's
+behalf before calling the preparer function.  It is your responsibility to
+process them before you return, raising an error for any unknown options that
+are passed.
+
+One very important responsibility of this function is the processing of SQL
+statement parameters. At the time of this call, PDO does not know if your
+driver supports binding parameters into prepared statements, nor does it
+know if it supports named or positional parameter naming conventions.
+
+Your driver is responsible for setting
+``stmt->supports_placeholders`` as appropriate for the
+underlying database.  This may involve some run-time determination on the
+part of your driver, if this setting depends on the version of the database
+server to which it is connected.  If your driver doesn't directly support
+both named and positional parameter conventions, you should use the
+``pdo_parse_params`` API to have PDO rewrite the query to
+take advantage of the support provided by your database.
+
+Example: Using pdo_parse_params
+
+.. code-block:: c
+
+    int ret;
+    char *nsql = NULL;
+    int nsql_len = 0;
+
+    /* before we prepare, we need to peek at the query; if it uses named parameters,
+     * we want PDO to rewrite them for us */
+    stmt->supports_placeholders = PDO_PLACEHOLDER_POSITIONAL;
+    ret = pdo_parse_params(stmt, (char*)sql, sql_len, &nsql, &nsql_len TSRMLS_CC);
+
+    if (ret == 1) {
+        /* query was re-written */
+        sql = nsql;
+    } else if (ret == -1) {
+        /* couldn't grok it */
+        strcpy(dbh->error_code, stmt->error_code);
+        return 0;
+    }
+
+    /* now proceed to prepare the query in "sql" */
+
+Possible values for ``supports_placeholders`` are:
+``PDO_PLACEHOLDER_NAMED``,
+``PDO_PLACEHOLDER_POSITIONAL`` and
+``PDO_PLACEHOLDER_NONE``.  If the driver doesn't support prepare statements at all, then this function should simply allocate any state that it might need, and then return:
+
+Example: Implementing preparer for drivers that don't support native prepared statements
+
+.. code-block:: c
+
+    static int SKEL_handle_preparer(pdo_dbh_t *dbh, const char *sql,
+        long sql_len, pdo_stmt_t *stmt, zval *driver_options TSRMLS_DC)
+    {
+        pdo_SKEL_db_handle *H = (pdo_SKEL_db_handle *)dbh->driver_data;
+        pdo_SKEL_stmt *S = ecalloc(1, sizeof(pdo_SKEL_stmt));
+
+        S->H = H;
+        stmt->driver_data = S;
+        stmt->methods = &SKEL_stmt_methods;
+        stmt->supports_placeholders = PDO_PLACEHOLDER_NONE;
+
+        return 1;
+    }
+
+This function returns 1 on success or 0 on failure.
+
+SKEL_handle_doer
+^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static long SKEL_handle_doer(pdo_dbh_t *dbh, const char *sql, long sql_len TSRMLS_DC)
+
+This function will be called by PDO to execute a raw SQL
+statement. No pdo_stmt_t is created.
+
+dbh
+    Pointer to the database handle initialized by the handle factory
+sql
+    Pointer to a character string containing the SQL statement to be prepared.
+sql_len
+    The length of the SQL statement.
+
+This function returns 1 on success or 0 on failure.
+
+SKEL_handle_quoter
+^^^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static int SKEL_handle_quoter(pdo_dbh_t *dbh, const char *unquoted,
+        int unquoted_len, char **quoted, int quoted_len, enum pdo_param_type param_type TSRMLS_DC)
+
+This function will be called by PDO to turn an unquoted
+string into a quoted string for use in a query.
+
+dbh
+    Pointer to the database handle initialized by the handle factory
+unquoted
+    Pointer to a character string containing the string to be quoted.
+unquoted_len
+    The length of the string to be quoted.
+quoted
+    Pointer to the address where a pointer to the newly quoted string will be returned.
+quoted_len
+    The length of the new string.
+param_type
+    A driver specific hint for driver that have alternate quoting styles
+
+This function is called in response to a call to
+``PDO::quote`` or when the driver has set
+``supports_placeholder`` to
+``PDO_PLACEHOLDER_NONE``. The purpose is to quote a
+parameter when building SQL statements.
+
+If your driver does not support native prepared statements, implementation
+of this function is required.
+
+This function returns 1 if the quoting process reformatted the string, and
+0 if it was not necessary to change the string. The original string will be
+used unchanged with a 0 return.
+
+SKEL_handle_begin
+^^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static int SKEL_handle_begin(pdo_dbh_t *dbh TSRMLS_DC)
+
+This function will be called by PDO to begin a database transaction.
+
+dbh
+    Pointer to the database handle initialized by the handle factory
+
+This should do whatever database specific activity that needs to be
+accomplished to begin a transaction. This function returns 1 for success or
+0 if an error occurred.
+
+SKEL_handle_commit
+^^^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static int SKEL_handle_commit(pdo_dbh_t *dbh TSRMLS_DC)
+
+This function will be called by PDO to end a database
+transaction.
+
+dbh
+    Pointer to the database handle initialized by the handle factory
+
+This should do whatever database specific activity that needs to be
+accomplished to commit a transaction. This function returns 1 for success or 0 if an error occurred.
+
+SKEL_handle_rollback
+^^^^^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static int SKEL_handle_rollback( pdo_dbh_t *dbh TSRMLS_DC)]]
+
+This function will be called by PDO to rollback a database transaction.
+
+dbh
+    Pointer to the database handle initialized by the handle factory
+
+This should do whatever database specific activity that needs to be
+accomplished to rollback a transaction. This function returns 1 for
+success or 0 if an error occurred.
+
+SKEL_handle_get_attribute
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static int SKEL_handle_get_attribute(pdo_dbh_t *dbh, long attr, zval *return_value TSRMLS_DC)
+
+This function will be called by PDO to retrieve a database attribute.
+
+dbh
+    Pointer to the database handle initialized by the handle factory
+attr
+    ``long`` value of one of the PDO_ATTR_xxxx types.
+    See :ref:`pdo_attributes` for valid attributes.
+return_value
+    The returned value for the attribute.
+
+It is up to the driver to decide which attributes will be supported for a
+particular implementation. It is not necessary for a driver to supply this
+function. PDO driver handles the PDO_ATTR_PERSISTENT, PDO_ATTR_CASE,
+PDO_ATTR_ORACLE_NULLS, and PDO_ATTR_ERRMODE attributes directly. 
+
+This function returns 1 on success or 0 on failure.
+
+SKEL_handle_set_attribute
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static int SKEL_handle_set_attribute(pdo_dbh_t *dbh, long attr, zval *val TSRMLS_DC)
+
+This function will be called by PDO to set a database attribute, usually in
+response to a script calling ``PDO::setAttribute``.
+
+dbh
+    Pointer to the database handle initialized by the handle factory
+attr
+    ``long`` value of one of the PDO_ATTR_xxxx types.
+    See :ref:`pdo_attributes` for valid attributes.
+val
+    The new value for the attribute.
+
+It is up to the driver to decide which attributes will be supported for a
+particular implementation. It is not necessary for a driver to provide this
+function if it does not need to support additional attributes. The PDO
+driver handles the PDO_ATTR_CASE, PDO_ATTR_ORACLE_NULLS, and
+PDO_ATTR_ERRMODE attributes directly. 
+
+This function returns 1 on success or 0 on failure.
+
+SKEL_handle_last_id
+^^^^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static char * SKEL_handle_last_id(pdo_dbh_t *dbh, const char *name, unsigned int len TSRMLS_DC)
+
+This function will be called by PDO to retrieve the ID of the last inserted
+row.
+
+dbh
+    Pointer to the database handle initialized by the handle factory
+name
+    string representing a table or sequence name.
+len
+    the length of the ``name`` parameter.
+
+This function returns a character string containing the id of the last
+inserted row on success or NULL on failure. This is an optional function. 
+
+SKEL_check_liveness
+^^^^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static int SKEL_check_liveness(pdo_dbh_t *dbh TSRMLS_DC)
+
+This function will be called by PDO to test whether or not a persistent
+connection to a database is alive and ready for use.
+
+dbh
+    Pointer to the database handle initialized by the handle factory
+
+This function returns 1 if the database connection is alive and ready
+for use, otherwise it should return 0 to indicate failure or lack
+of support.
+
+.. note:: This is an optional function.
+
+SKEL_get_driver_methods
+^^^^^^^^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static function_entry *SKEL_get_driver_methods(pdo_dbh_t *dbh, int kind TSRMLS_DC)
+
+This function will be called by PDO in response to a call to any method
+that is not a part of either the ``PDO`` or
+``PDOStatement`` classes.  It's purpose is to allow the
+driver to provide additional driver specific methods to those classes.
+
+dbh
+    Pointer to the database handle initialized by the handle factory
+kind
+    One of the following:
+
+        PDO_DBH_DRIVER_METHOD_KIND_DBH
+            Set when the method call was attempted on an instance of the
+            ``PDO`` class.  The driver should return a pointer
+            a function_entry table for any methods it wants to add to that class,
+            or NULL if there are none.
+        PDO_DBH_DRIVER_METHOD_KIND_STMT
+            Set when the method call was attempted on an instance of the
+            ``PDOStatement`` class.  The driver should return
+            a pointer to a function_entry table for any methods it wants to add
+            to that class, or NULL if there are none.
+
+This function returns a pointer to the function_entry table requested,
+or NULL there are no driver specific methods.
+
+SKEL_handle_factory
+^^^^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static int SKEL_handle_factory(pdo_dbh_t *dbh, zval *driver_options TSRMLS_DC)
+
+This function will be called by PDO to create a database handle. For most
+databases this involves establishing a connection to the database. In some
+cases, a persistent connection may be requested, in other cases connection
+pooling may be requested. All of these are database/driver dependent.
+
+dbh
+    Pointer to the database handle initialized by the handle factory
+driver_options
+    An array of driver options, keyed by integer option number.
+    See :ref:`pdo_attributes` for a list of possible attributes.
+
+This function should fill in the passed database handle structure with its
+driver specific information on success and return 1, otherwise it should
+return 0 to indicate failure.
+
+PDO processes the AUTOCOMMIT and PERSISTENT driver options
+before calling the handle_factory. It is the handle factory's
+responsibility to process other options.
+
+Driver method table
+^^^^^^^^^^^^^^^^^^^
+
+A static structure of type pdo_dbh_methods named SKEL_methods must be
+declared and initialized to the function pointers for each defined
+function. If a function is not supported or not implemented the value for
+that function pointer should be set to NULL.
+
+pdo_SKEL_driver
+^^^^^^^^^^^^^^^
+
+A structure of type pdo_driver_t named pdo_SKEL_driver should be declared.
+The PDO_DRIVER_HEADER(SKEL) macro should be used to declare the header and
+the function pointer to the handle factory function should set.
+
+SKEL_statement.c: Statement implementation
+------------------------------------------
+
+This unit implements all of the database statement handling methods that
+support the PDO statement object.
+
+SKEL_stmt_dtor
+^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static int SKEL_stmt_dtor(pdo_stmt_t *stmt TSRMLS_DC)
+
+This function will be called by PDO to destroy a previously constructed statement object.
+
+stmt
+    Pointer to the statement structure initialized by SKEL_handle_preparer.
+
+This should do whatever is necessary to free up any driver specific storage
+allocated for the statement. The return value from this function is
+ignored.
+
+SKEL_stmt_execute
+^^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static int SKEL_stmt_execute(pdo_stmt_t *stmt TSRMLS_DC)
+
+This function will be called by PDO to execute the prepared SQL statement
+in the passed statement object.
+
+stmt
+    Pointer to the statement structure initialized by SKEL_handle_preparer.
+
+This function returns 1 for success or 0 in the event of failure.
+
+SKEL_stmt_fetch
+^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static int SKEL_stmt_fetch(pdo_stmt_t *stmt, enum pdo_fetch_orientation ori,
+        long offset TSRMLS_DC)
+
+This function will be called by PDO to fetch a row from a previously
+executed statement object.
+
+stmt
+    Pointer to the statement structure initialized by SKEL_handle_preparer.
+ori
+    One of PDO_FETCH_ORI_xxx which will determine which row will be fetched.
+offset
+    If ori is set to PDO_FETCH_ORI_ABS or PDO_FETCH_ORI_REL, offset
+    represents the row desired or the row relative to the current position,
+    respectively. Otherwise, this value is ignored.
+
+The results of this fetch are driver dependent and the data is usually
+stored in the driver_data member of the pdo_stmt_t object. The ori and
+offset parameters are only meaningful if the statement represents a
+scrollable cursor. This function returns 1 for success or 0 in the event of
+failure.
+
+SKEL_stmt_param_hook
+^^^^^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static int SKEL_stmt_param_hook(pdo_stmt_t *stmt,
+        struct pdo_bound_param_data *param, enum pdo_param_event event_type TSRMLS_DC)
+
+This function will be called by PDO for handling of both bound parameters and bound columns.
+
+stmt
+    Pointer to the statement structure initialized by SKEL_handle_preparer.
+param
+    The structure describing either a statement parameter or a bound column.
+event_type
+    The type of event to occur for this parameter, one of the following:
+
+    PDO_PARAM_EVT_ALLOC
+        Called when PDO allocates the binding.  Occurs as part of
+        ``PDOStatement::bindParam``,
+        ``PDOStatement::bindValue`` or as part of an implicit bind
+        when calling ``PDOStatement::execute``.  This is your
+        opportunity to take some action at this point; drivers that implement
+        native prepared statements will typically want to query the parameter
+        information, reconcile the type with that requested by the script,
+        allocate an appropriately sized buffer and then bind the parameter to
+        that buffer.  You should not rely on the type or value of the zval at
+        ``param->parameter`` at this point in time.
+    PDO_PARAM_EVT_FREE
+        Called once per parameter as part of cleanup.  You should
+        release any resources associated with that parameter now.
+    PDO_PARAM_EXEC_PRE
+        Called once for each parameter immediately before calling
+        SKEL_stmt_execute; take this opportunity to make any final adjustments
+        ready for execution.  In particular, you should note that variables
+        bound via ``PDOStatement::bindParam`` are only legal
+        to touch now, and not any sooner.
+    PDO_PARAM_EXEC_POST
+        Called once for each parameter immediately after calling
+        SKEL_stmt_execute; take this opportunity to make any post-execution
+        actions that might be required by your driver.
+    PDO_PARAM_FETCH_PRE
+        Called once for each parameter immediately prior to calling
+        SKEL_stmt_fetch.
+    PDO_PARAM_FETCH_POST
+        Called once for each parameter immediately after calling
+        SKEL_stmt_fetch.
+
+This hook will be called for each bound parameter and bound column in the
+statement. For ALLOC and FREE events, a single call will be made for each
+parameter or column. The param structure contains a driver_data field that
+the driver can use to store implementation specific information about each
+of the parameters.
+
+For all other events, PDO may call you multiple times as the script issues
+``PDOStatement::execute`` and
+``PDOStatement::fetch`` calls.
+
+If this is a bound parameter, the is_param flag in the param structure is
+set, otherwise the param structure refers to a bound column.
+
+This function returns 1 for success or 0 in the event of failure.
+
+SKEL_stmt_describe_col
+^^^^^^^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static int SKEL_stmt_describe_col(pdo_stmt_t *stmt, int colno TSRMLS_DC)
+
+This function will be called by PDO to query information about a particular
+column.
+
+stmt
+    Pointer to the statement structure initialized by SKEL_handle_preparer.
+colno
+    The column number to be queried.
+
+The driver should populate the pdo_stmt_t member columns(colno) with the
+appropriate information. This function returns 1 for success or 0 in the
+event of failure.
+
+SKEL_stmt_get_col_data
+^^^^^^^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static int SKEL_stmt_get_col_data(pdo_stmt_t *stmt, int colno,
+        char **ptr, unsigned long *len, int *caller_frees TSRMLS_DC)
+
+This function will be called by PDO to retrieve data from the specified column.
+
+stmt
+    Pointer to the statement structure initialized by SKEL_handle_preparer.
+colno
+    The column number to be queried.
+ptr
+    Pointer to the retrieved data.
+len
+    The length of the data pointed to by ptr.
+caller_frees
+    If set, ptr should point to emalloc'd memory and the main PDO driver will free it as soon as it is done with it. Otherwise, it will be the responsibility of the driver to free any allocated memory as a result of this call.
+
+The driver should return the resultant data and length of that data in the
+ptr and len variables respectively. It should be noted that the main PDO
+driver expects the driver to manage the lifetime of the data. This function
+returns 1 for success or 0 in the event of failure.
+
+SKEL_stmt_set_attr
+^^^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static int SKEL_stmt_set_attr(pdo_stmt_t *stmt, long attr, zval *val TSRMLS_DC)
+
+This function will be called by PDO to allow the setting of driver specific
+attributes for a statement object.
+
+stmt
+    Pointer to the statement structure initialized by SKEL_handle_preparer.
+attr
+    ``long`` value of one of the PDO_ATTR_xxxx types.
+    See :ref:`pdo_attributes` for valid attributes.
+val
+    The new value for the attribute.
+
+This function is driver dependent and allows the driver the capability to
+set database specific attributes for a statement. This function returns 1
+for success or 0 in the event of failure. This is an optional function. If
+the driver does not support additional settable attributes, it can be
+NULLed in the method table. The PDO driver does not handle any settable
+attributes on the database driver's behalf.
+
+SKEL_stmt_get_attr
+^^^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static int SKEL_stmt_get_attr(pdo_stmt_t *stmt, long attr, zval
+        *return_value TSRMLS_DC)
+
+This function will be called by PDO to allow the retrieval of driver
+specific attributes for a statement object.
+
+stmt
+    Pointer to the statement structure initialized by SKEL_handle_preparer.
+attr
+    ``long`` value of one of the PDO_ATTR_xxxx types.
+    See :ref:`pdo_attributes` for valid attributes.
+return_value
+    The returned value for the attribute.
+
+This function is driver dependent and allows the driver the capability to
+retrieve a previously set database specific attribute for a statement. This
+function returns 1 for success or 0 in the event of failure. This is an
+optional function. If the driver does not support additional gettable
+attributes, it can be NULLed in the method table. The PDO driver does not
+handle any settable attributes on the database driver's behalf.
+
+SKEL_stmt_get_col_meta
+^^^^^^^^^^^^^^^^^^^^^^
+
+.. code-block:: c
+
+    static int SKEL_stmt_get_col_meta(pdo_stmt_t *stmt, int colno,
+        zval *return_value TSRMLS_DC)
+
+.. warning:: This function is not well defined and is subject to change.
+
+This function will be called by PDO to retrieve meta data from the
+specified column.
+
+stmt
+    Pointer to the statement structure initialized by SKEL_handle_preparer.
+colno
+    The column number for which data is to be retrieved.
+return_value
+    Holds the returned meta data.
+
+The driver author should consult the documentation for this function that can be
+found in the php_pdo_driver.h header as this will be the most current. This
+function returns ``SUCCESS`` for success or ``FAILURE`` in the event of failure. The database
+driver does not need to provide this function.
+
+Statement handling method table
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A static structure of type pdo_stmt_methods named SKEL_stmt_methods should
+be declared and initialized to the function pointers for each defined
+function. If a function is not supported or not implemented the value for
+that function pointer should be set to NULL.
diff --git a/Book/php7/pdo/packaging.rst b/Book/php7/pdo/packaging.rst
new file mode 100644
index 00000000..2353b5f8
--- /dev/null
+++ b/Book/php7/pdo/packaging.rst
@@ -0,0 +1,41 @@
+Packaging and distribution
+==========================
+
+Creating a package
+------------------
+
+PDO drivers are released via PECL; all the usual rules for PECL extensions
+apply.  Packaging is accomplished by creating a valid
+``package.xml`` file and then running:
+
+.. code-block:: none
+
+    $ pecl package
+
+This will create a tarball named ``PDO_SKEL-X.Y.Z.tgz``.
+
+Before releasing the package, you should test that it builds correctly; if
+you've made a mistake in your ``config.m4`` or
+``package.xml`` files, the package may not function
+correctly.  You can test the build, without installing anything, using the
+following invocation:
+
+.. code-block:: bash
+
+    $ pecl build package.xml
+
+Once this is proven to work, you can test installation:
+
+.. code-block:: bash
+
+    $ pecl package
+    $ sudo pecl install PDO_SKEL-X.Y.X.tgz
+
+Full details about ``package.xml`` can be found in the PEAR
+Programmer's documentation (`<https://pear.php.net/manual/>`_).
+
+Releasing the package
+---------------------
+
+A PDO driver is released via the PHP Extension Community Library (PECL).
+Information about PECL can be found at `<https://pecl.php.net/>`_.
diff --git a/Book/php7/pdo/pdo-dbh-t.rst b/Book/php7/pdo/pdo-dbh-t.rst
new file mode 100644
index 00000000..d2745932
--- /dev/null
+++ b/Book/php7/pdo/pdo-dbh-t.rst
@@ -0,0 +1,142 @@
+.. _pdo_dbh_t:
+
+pdo_dbh_t definition
+====================
+
+All fields should be treated as read-only by the driver, unless explicitly
+stated otherwise.
+
+.. code-block:: c
+
+    /* represents a connection to a database */
+    struct _pdo_dbh_t {
+        /* driver specific methods */
+        struct pdo_dbh_methods *methods;
+
+The driver *must* set this during
+``SKEL_handle_factory``.
+
+.. code-block:: c
+
+        /* driver specific data */
+        void *driver_data;
+
+This item is for use by the driver; the intended usage is to store a
+pointer (during ``SKEL_handle_factory``) 
+to whatever instance data is required to maintain a connection to
+the database.
+
+.. code-block:: c
+
+        /* credentials */
+        char *username, *password;
+
+The username and password that were passed into the PDO constructor.
+The driver should use these values when it initiates a connection to the
+database.
+
+.. code-block:: c
+
+        /* if true, then data stored and pointed at by this handle must all be
+         * persistently allocated */
+        unsigned is_persistent:1;
+
+If this is set to 1, then any data that is referenced by the
+dbh, including whatever structure your driver allocates,
+*MUST* be allocated persistently.  This is easy to
+achieve; rather than using the usual ``emalloc`` simply
+use ``pemalloc`` and pass the value of this flag as the
+last parameter.  Failure to use the appropriate kind of memory can lead
+to serious memory faults, resulting (in the best case) a hard crash, and
+in the worst case, an exploitable memory problem.
+
+If, for whatever reason, your driver is not suitable to run persistently,
+you *MUST* check this flag in your
+``SKEL_handle_factory`` and raise an appropriate error.
+
+.. code-block:: c
+
+        /* if true, driver should act as though a COMMIT were executed between
+         * each executed statement; otherwise, COMMIT must be carried out manually */
+        unsigned auto_commit:1;
+
+You should check this value in your ``SKEL_handle_doer``
+and ``SKEL_stmt_execute`` functions; if it evaluates to
+true, you must attempt to commit the query now.  Most database
+implementations offer an auto-commit mode that handles this automatically.
+
+.. code-block:: c
+
+        /* if true, the driver requires that memory be allocated explicitly for
+        * the columns that are returned */
+        unsigned alloc_own_columns:1;
+
+If your database client library API operates by fetching data into a
+caller-supplied buffer, you should set this flag to 1 during your
+``SKEL_handle_factory``.  When set, PDO will call your
+``SKEL_stmt_describer`` earlier than it would
+otherwise.  This early call allows you to determine those buffer sizes
+and issue appropriate calls to the database client library.
+
+If your database client library API simply returns pointers to its own
+internal buffers for you to copy after each fetch call, you should leave
+this value set to 0.
+
+.. code-block:: c
+
+        /* if true, commit or rollBack is allowed to be called */
+        unsigned in_txn:1;                  
+
+        /* max length a single character can become after correct quoting */
+        unsigned max_escaped_char_length:3;
+
+If your driver doesn't support native prepared statements
+(``supports_placeholders`` is set to
+``PDO_PLACEHOLDER_NONE``), you must set
+this value to the maximum length that can be taken up by a single
+character when it is quoted by your
+``SKEL_handle_quoter`` function.  This value is used to
+calculate the amount of buffer space required when PDO executes the
+statement.
+
+.. code-block:: c
+
+        /* data source string used to open this handle */
+        const char *data_source;
+
+This holds the value of the DSN that was passed into the PDO
+constructor.  If your driver implementation needed to modify the DSN for
+whatever reason, it should update this member during
+``SKEL_handle_factory``.  Modifying this member should
+be avoided.  If you do change it, you must ensure that
+``data_source_len`` is also correct.
+
+.. code-block:: c
+
+        unsigned long data_source_len;
+
+        /* the global error code. */
+        pdo_error_type error_code;
+
+Whenever an error occurs during a call to one of your driver methods,
+you should set this member to the SQLSTATE code that best describes the
+error and return an error.  In this HOW-TO, the suggested practice is to
+call ``SKEL_handle_error`` when an error is detected,
+and have it set the error code.
+
+.. code-block:: c
+
+        enum pdo_case_conversion native_case, desired_case;
+    };
+
+Your driver should set this during
+``SKEL_handle_factory``; the value should reflect how
+the database returns the names of the columns in result sets.  If the
+name matches the case that was used in the query, set it to
+``PDO_CASE_NATURAL`` (this is actually the default).
+If the column names are always returned in upper case, set it to
+``PDO_CASE_UPPER``.  If the column names are always
+returned in lower case, set it to ``PDO_CASE_LOWER``.
+The value you set is used to determine if PDO should perform case
+folding when the user sets the ``PDO_ATTR_CASE``
+attribute.
diff --git a/Book/php7/pdo/pdo-stmt-t.rst b/Book/php7/pdo/pdo-stmt-t.rst
new file mode 100644
index 00000000..d8166a74
--- /dev/null
+++ b/Book/php7/pdo/pdo-stmt-t.rst
@@ -0,0 +1,107 @@
+.. _pdo_stmt_t:
+
+pdo_stmt_t definition
+=====================
+
+All fields should be treated as read-only unless explicitly stated
+otherwise.
+
+.. code-block:: c
+
+    /* represents a prepared statement */
+    struct _pdo_stmt_t {
+        /* driver specifics */
+        struct pdo_stmt_methods *methods;
+
+The driver *must* set this during
+``SKEL_handle_preparer``.
+
+.. code-block:: c
+
+        void *driver_data;
+
+This item is for use by the driver; the intended usage is to store a
+pointer (during ``SKEL_handle_factory``) 
+to whatever instance data is required to maintain a connection to
+the database.
+
+.. code-block:: c
+
+        /* if true, we've already successfully executed this statement at least
+         * once */
+        unsigned executed:1;
+
+This is set by PDO after the statement has been executed for the first
+time.  Your driver can inspect this value to determine if it can skip
+one-time actions as an optimization.
+
+.. code-block:: c
+
+        /* if true, the statement supports placeholders and can implement
+         * bindParam() for its prepared statements, if false, PDO should
+         * emulate prepare and bind on its behalf */
+        unsigned supports_placeholders:2;
+
+Discussed in more detail in :ref:`pdo_preparer`.
+
+.. code-block:: c
+
+        /* the number of columns in the result set; not valid until after
+         * the statement has been executed at least once.  In some cases, might
+         * not be valid until fetch (at the driver level) has been called at least once. */
+        int column_count;
+
+Your driver is responsible for setting this field to the number of
+columns available in a result set.  This is usually set during
+``SKEL_stmt_execute`` but with some database
+implementations, the column count may not be available until
+``SKEL_stmt_fetch`` has been called at least once.
+Drivers that implement ``SKEL_stmt_next_rowset`` should
+update the column count when a new rowset is available.
+
+.. code-block:: c
+
+        struct pdo_column_data *columns;
+
+PDO will allocate this field based on the value that you set for the
+column count.  You are responsible for populating each column during
+``SKEL_stmt_describe``.  You must set the
+``precision``, ``maxlen``,
+``name``, ``namelen`` and
+``param_type`` members for each column.
+The ``name`` is expected to be allocated using
+``emalloc``; PDO will call ``efree`` at
+the appropriate time.
+
+.. code-block:: c
+
+        /* points at the dbh that this statement was prepared on */
+        pdo_dbh_t *dbh;
+
+        /* keep track of bound input parameters.  Some drivers support
+         * input/output parameters, but you can't rely on that working */
+        HashTable *bound_params;
+        /* When rewriting from named to positional, this maps positions to names */
+        HashTable *bound_param_map; 
+        /* keep track of PHP variables bound to named (or positional) columns
+         * in the result set */
+        HashTable *bound_columns;
+
+        /* not always meaningful */
+        long row_count;
+
+        /* used to hold the statement's current query */
+        char *query_string;
+        int query_stringlen;
+
+        /* the copy of the query with expanded binds ONLY for emulated-prepare drivers */
+        char *active_query_string;
+        int active_query_stringlen;
+
+        /* the cursor specific error code. */
+        pdo_error_type error_code;
+
+        /* used by the query parser for driver specific
+         * parameter naming (see pgsql driver for example) */
+        const char *named_rewrite_template;
+    };
diff --git a/Book/php7/pdo/preparation.rst b/Book/php7/pdo/preparation.rst
new file mode 100644
index 00000000..e51e70e5
--- /dev/null
+++ b/Book/php7/pdo/preparation.rst
@@ -0,0 +1,123 @@
+Preparation and Housekeeping
+============================
+
+Source directory layout
+-----------------------
+
+The source directory for a typical PDO driver is laid out as follows, where
+``SKEL`` represents a shortened form of the name of the
+database that the driver is going to connect to.  Even though SKEL is
+presented here in uppercase (for clarity), the convention is to use
+lowercase characters.
+
+.. code-block:: none
+
+    pdo_SKEL/          
+      config.m4                  # unix build script
+      config.w32                 # win32 build script
+      CREDITS
+      package.xml                # meta information about the package
+      pdo_SKEL.c                 # standard PHP extension glue
+      php_pdo_SKEL.h
+      php_pdo_SKEL_int.h         # driver private header
+      SKEL_dbh.c                 # contains the implementation of the PDO driver interface
+      SKEL_stmt.c                # contains the implementation of the PDO statement interface
+      tests/
+
+The contents of these files are defined later in this document.
+
+Creating a skeleton
+-------------------
+
+The easiest way to get started is to use the ``ext_skel``
+shell script found in the PHP build tree in the ``ext``
+directory. This will build a skeleton directory containing a lot of the
+files listed above. It can be build by executing the following command from
+within the ``ext`` directory:
+
+.. code-block:: none
+
+    ./ext_skel --extname=pdo_SKEL
+
+This will generate a directory called pdo_SKEL containing the
+skeleton files that you can then modify. This directory should then be
+moved out of the php extension directory. PDO is a PECL extension and
+should not be included in the standard extension directory. As long as you
+have PHP and PDO installed, you should be able to build from any directory.
+
+Standard Includes
+-----------------
+
+Build Specific Headers
+^^^^^^^^^^^^^^^^^^^^^^
+
+The header file config.h is generated by the configure process for the
+platform for which the driver is being built. If this header is
+present, the HAVE_CONFIG_H compiler variable is set. This variable should
+be tested for and if set, the file config.h should be included in the
+compilation unit.
+
+PHP Headers
+^^^^^^^^^^^
+
+The following standard public php headers should be included in each
+source module:
+
+#. php.h
+#. php_ini.h
+#. ext/standard/info.h
+
+PDO Interface Headers
+^^^^^^^^^^^^^^^^^^^^^
+
+The following standard public PDO header files are also included in each
+source module:
+
+pdo/php_pdo.h
+    This header file contains definitions of the initialization and shutdown
+    functions in the main driver as well as definitions of global PDO
+    variables.
+
+pdo/php_pdo_driver.h
+    This header contains the types and API contracts that are used to write
+    a PDO driver. It also contains method signature for calling back into
+    the PDO layer and registering/unregistering your driver with 
+    PDO. Most importantly, this header file contains the type
+    definitions for PDO database handles and statements. The two main
+    structures a driver has to deal with, pdo_dbh_t and pdo_stmt_t, are
+    described in more detail in later sections.
+
+Driver Specific Headers
+^^^^^^^^^^^^^^^^^^^^^^^
+
+The typical PDO driver has two header files that are specific to the
+database implementation. This does not preclude the use of more depending
+on the implementation. The following two headers are, by convention,
+standard:
+
+php_pdo_SKEL.h
+    This header file is virtually an exact duplicate in functionality
+    and content of the previously defined pdo/php_pdo.h that has been
+    specifically tailored for your database. If your driver requires
+    the use of global variables they should be defined using the
+    ZEND_BEGIN_MODULE_GLOBALS and ZEND_END_MODULE_GLOBALS macros.
+    Macros are then used to access these variables. This macro is
+    usually named PDO_SKEL_G(v) where v is global variable to be
+    accessed. Consult the Zend programmer documentation for more information.
+
+php_pdo_SKEL_int.h
+    This header file typically contains type definitions and function
+    declarations specific to the driver implementation. It also should
+    contain the db specific definitions of a pdo_SKEL_handle and
+    pdo_SKEL_stmt structures. These are the names of the private
+    data structures that are then referenced by the driver_data members
+    of the handle and statement structures.
+
+Optional Headers
+^^^^^^^^^^^^^^^^
+
+Depending on the implementation details for a particular driver it may be
+necessary to include the following header:
+::
+
+    #include <zend_exceptions.h>
diff --git a/Book/php7/pdo/prerequisites.rst b/Book/php7/pdo/prerequisites.rst
new file mode 100644
index 00000000..ae7ddb70
--- /dev/null
+++ b/Book/php7/pdo/prerequisites.rst
@@ -0,0 +1,23 @@
+Prerequisites
+=============
+
+The following is list of prerequisites and assumptions needed for writing
+a PDO database driver:
+ 
+#. A working target database, examples, demos, etc. working as per vendor
+   specifications
+
+#. A working development environment:
+
+   * Linux: standard development tools, gcc, ld, make, autoconf, automake, etc., versions dependent on distribution
+   * Other Unix: standard development tools supplied by vendor plus the GNU development tool set
+   * Win32: Visual Studio compiler suite
+
+#. A working PHP environment version 5.0.3 or higher with a working PEAR extension version 1.3.5 or higher
+#. A working PDO environment (can be installed using 'sudo pecl install PDO'), including the headers
+   which will be needed to access the PDO type definitions and function declarations
+#. A good working knowledge of the C programming language
+#. A good working knowledge of the way to write a PHP extension; George Schlossnagle's*
+   **Advanced PHP Programming** (published by Developer's Library, chapters 21 and 22) is recommended
+#. Finally, a familiarity with the Zend API that forms the heart of PHP, in
+   particular paying attention to the memory management aspects.
diff --git a/Book/php7/pdo/testing.rst b/Book/php7/pdo/testing.rst
new file mode 100644
index 00000000..a521e8e3
--- /dev/null
+++ b/Book/php7/pdo/testing.rst
@@ -0,0 +1,63 @@
+Testing
+=======
+
+PDO has a set of "core" tests that all drivers should pass before being
+released.  They're designed to run from the PHP source distribution, so
+running the tests for your driver requires moving things around a bit.
+The suggested procedure is to obtain the latest PHP 5.1 snapshot and
+perform the following step:
+
+.. code-block:: bash
+
+    $ cp -r pdo_SKEL /path/to/php-5.1/ext
+
+This will allow the test harness to run your tests.  The next thing you
+need to do is create a test that will redirect into the PDO common core tests.
+The convention is to name this file ``common.phpt``; it
+should be placed in the tests subdirectory that was created by
+``ext_skel`` when you created your extension skeleton.
+The content of this file should look something like the following:
+
+.. code-block:: php
+
+    --TEST--
+    SKEL
+    --SKIPIF--
+    <?php
+    if (!extension_loaded('pdo_SKEL')) print 'skip';
+    ?>
+    --REDIRECTTEST--
+    if (false !== getenv('PDO_SKEL_TEST_DSN')) {
+        # user set them from their shell
+        $config['ENV']['PDOTEST_DSN'] = getenv('PDO_SKEL_TEST_DSN');
+        $config['ENV']['PDOTEST_USER'] = getenv('PDO_SKEL_TEST_USER');
+        $config['ENV']['PDOTEST_PASS'] = getenv('PDO_SKEL_TEST_PASS');
+        if (false !== getenv('PDO_SKEL_TEST_ATTR')) {
+            $config['ENV']['PDOTEST_ATTR'] = getenv('PDO_SKEL_TEST_ATTR');
+        }
+        return $config;
+    }
+    return array(
+        'ENV' => array(
+            'PDOTEST_DSN' => 'SKEL:dsn',
+            'PDOTEST_USER' => 'username',
+            'PDOTEST_PASS' => 'password'
+        ),
+        'TESTS' => 'ext/pdo/tests'
+    );
+
+This will cause the common core tests to be run, passing the values of
+``PDOTEST_DSN``, ``PDOTEST_USER`` and
+``PDOTEST_PASS`` to the PDO constructor as the
+``dsn``, ``username`` and
+``password`` parameters.  It will first check the environment, so
+that appropriate values can be passed in when the test harness is run,
+rather than hard-coding the database credentials into the test file.
+
+The test harness can be invoked as follows:
+
+.. code-block:: bash
+
+    $ cd /path/to/php-5.1
+    $ make TESTS=ext/pdo_SKEL/tests PDO_SKEL_TEST_DSN="skel:dsn" \
+      PDO_SKEL_TEST_USER=user PDO_SKEL_TEST_PASS=pass test