Filewatcher File Search File Search
Content Search
» » » » » » perl-DBD-Pg-2.15.1-4.el6_3.x86_64.rpm » Content »
pkg://perl-DBD-Pg-2.15.1-4.el6_3.x86_64.rpm:201172/usr/share/man/man3/  info  HEADER  downloads

perl-DBD-Pg - A PostgreSQL interface for perl…  more info»


Pg(3)            User Contributed Perl Documentation           Pg(3)

       DBD::Pg - PostgreSQL database driver for the DBI module

         use DBI;

         $dbh = DBI->connect("dbi:Pg:dbname=$dbname", '', '', {AutoCommit => 0});
         # The AutoCommit attribute should always be explicitly set

         # For some advanced uses you may need PostgreSQL type values:
         use DBD::Pg qw(:pg_types);

         # For asynchronous calls, import the async constants:
         use DBD::Pg qw(:async);

         $dbh->do('INSERT INTO mytable(a) VALUES (1)');

         $sth = $dbh->prepare('INSERT INTO mytable(a) VALUES (?)');

       This documents version 2.15.1 of the DBD::Pg module

       DBD::Pg is a Perl module that works with the DBI module to
       provide access to PostgreSQL databases.

       This documentation describes driver specific behavior and
       restrictions. It is not supposed to be used as the only
       reference for the user. In any case consult the DBI
       documentation first!

   DBI Class Methods

       This method creates a database handle by connecting to a
       database, and is the DBI equivalent of the "new" method. To
       connect to a Postgres database with a minimum of parameters,
       use the following syntax:

         $dbh = DBI->connect("dbi:Pg:dbname=$dbname", '', '', {AutoCommit => 0});

       This connects to the database named in the $dbname variable
       on the default port (usually 5432) without any user

       The following connect statement shows almost all possible

         $dbh = DBI->connect("dbi:Pg:dbname=$dbname;host=$host;port=$port;options=$options",
                             {AutoCommit => 0, RaiseError => 1, PrintError => 0}

       If a parameter is not given, the connect() method will first
       look for specific environment variables, and then fall back
       to hard-coded defaults:

         parameter    environment variable    hard coded default
         host         PGHOST                  local domain socket
         hostaddr     PGHOSTADDR              local domain socket
         port         PGPORT                  5432
         dbname*      PGDATABASE              current userid
         username     PGUSER                  current userid
         password     PGPASSWORD              (none)
         options      PGOPTIONS               (none)
         service      PGSERVICE               (none)
         sslmode      PGSSLMODE               (none)

       * May also use the aliases "db" or "database"

       If the username and password values passed via "connect()"
       are undefined (as opposed to merely being empty strings), DBI
       will use the environment variables DBI_USER and DBI_PASS if
       they exist.

       You can also connect by using a service connection file,
       which is named pg_service.conf. The location of this file can
       be controlled by setting the PGSYSCONFDIR environment
       variable. To use one of the named services within the file,
       set the name by using either the service parameter or the
       environment variable PGSERVICE. Note that when connecting
       this way, only the minimum parameters should be used. For
       example, to connect to a service named "zephyr", you could

         $dbh = DBI->connect("dbi:Pg:service=zephyr", '', '');

       You could also set $ENV{PGSERVICE} to "zephyr" and connect
       like this:

         $dbh = DBI->connect("dbi:Pg:", '', '');

       The format of the pg_service.conf file is simply a bracketed
       service name, followed by one parameter per line in the
       format name=value.  For example:


       There are four valid arguments to the sslmode parameter,
       which controls whether to use SSL to connect to the database:

       ·   disable: SSL connections are never used

       ·   allow: try non-SSL, then SSL

       ·   prefer: try SSL, then non-SSL

       ·   require: connect only with SSL

       You can also connect using sockets in a specific directory.
       This may be needed if the server you are connecting to has a
       different default socket directory from the one used to
       compile DBD::Pg.  Use the complete path to the socket
       directory as the name of the host, like this:

         $dbh = DBI->connect('dbi:Pg:dbname=foo;host=/var/tmp/socket',
           {AutoCommit => 0, RaiseError => 1});

       The attribute hash can also contain a key named
       "dbd_verbose", which simply calls "$dbh-"trace('DBD')> after
       the handle is created. This attribute is not recommended, as
       it is clearer to simply explicitly call "trace" explicitly in
       your script.


         $dbh = DBI->connect_cached("dbi:Pg:dbname=$dbname", $username, $password, \%options);

       Implemented by DBI, no driver-specific impact.


         @data_sources = DBI->data_sources('Pg');
         @data_sources = $dbh->data_sources();

       Returns a list of available databases. Unless the environment
       variable "DBI_DSN" is set, a connection will be attempted to
       the database "template1". The normal connection environment
       variables also apply, such as "PGHOST", "PGPORT", "DBI_USER",
       "DBI_PASS", and "PGSERVICE".

       You can also pass in options to add to the connection string
       For example, to specify an alternate port and host:

         @data_sources = DBI->data_sources('Pg', 'port=5824;');


         @data_sources = $dbh->data_sources('port=5824;');

   Methods Common To All Handles
       For all of the methods below, $h can be either a database
       handle ($dbh) or a statement handle ($sth). Note that $dbh
       and $sth can be replaced with any variable name you choose:
       these are just the names most often used. Another common
       variable used in this documentation is $rv, which stands for
       "return value".


         $rv = $h->err;

       Returns the error code from the last method called. For the
       connect method it returns "PQstatus", which is a number used
       by libpq (the Postgres connection library). A value of 0
       indicates no error (CONNECTION_OK), while any other number
       indicates a failed connection. The only other number commonly
       seen is 1 (CONNECTION_BAD). See the libpq documentation for
       the complete list of return codes.

       In all other non-connect methods "$h-"err> returns the
       "PQresultStatus" of the current handle. This is a number used
       by libpq and is one of:

         0  Empty query string
         1  A command that returns no data successfully completed.
         2  A command that returns data sucessfully completed.
         3  A COPY OUT command is still in progress.
         4  A COPY IN command is still in progress.
         5  A bad response was received from the backend.
         6  A nonfatal error occurred (a notice or warning message)
         7  A fatal error was returned: the last query failed.


         $str = $h->errstr;

       Returns the last error that was reported by Postgres. This
       message is affected by the "pg_errorlevel" setting.


         $str = $h->state;

       Returns a five-character "SQLSTATE" code. Success is
       indicated by a 00000 code, which gets mapped to an empty
       string by DBI. A code of "S8006" indicates a connection
       failure, usually because the connection to the Postgres
       server has been lost.

       While this method can be called as either "$sth-"state> or
       "$dbh-"state>, it is usually clearer to always use

       The list of codes used by PostgreSQL can be found at:

       Note that these codes are part of the SQL standard and only a
       small number of them will be used by PostgreSQL.

       Common codes:

         00000 Successful completion
         25P01 No active SQL transaction
         25P02 In failed SQL transaction
         S8006 Connection failure


         $h->trace($trace_settings, $trace_filename);
         $trace_settings = $h->trace;

       Changes the trace settings on a database or statement handle.
       The optional second argument specifies a file to write the
       trace information to. If no filename is given, the
       information is written to STDERR. Note that tracing can be
       set globally as well by setting "DBI->trace", or by using the
       environment variable DBI_TRACE.

       The value is either a numeric level or a named flag. For the
       flags that DBD::Pg uses, see parse_trace_flag.


         $h->trace_msg($message_text, $min_level);

       Writes a message to the current trace output (as set by the
       "trace" method). If a second argument is given, the message
       is only written if the current tracing level is equal to or
       greater than the $min_level.

       parse_trace_flag and parse_trace_flags


         ## Simpler:

         my $value = DBD::Pg->parse_trace_flag('pglibpq');

       The parse_trace_flags method is used to convert one or more
       named flags to a number which can passed to the "trace"
       method.  DBD::Pg currently supports the DBI-specific flag,
       "SQL", as well as the ones listed below.

       Flags can be combined by using the parse_trace_flags method,
       which simply calls "parse_trace_flag" on each item and
       combines them.

       Sometimes you may wish to turn the tracing on before you
       connect to the database. The second example above shows a way
       of doing this: the call to "DBD::Pg->parse_trace_flags"
       provides a number than can be fed to "DBI->trace" before you
       create a database handle.

       DBD::Pg supports the following trace flags:

       SQL Outputs all SQL statements. Note that the output provided
           will not necessarily be in a form suitable to passing
           directly to Postgres, as server-side prepared statements
           are used extensively by DBD::Pg.  For maximum portability
           of output (but with a potential performance hit), use
           with "$dbh-"{pg_server_prepare} = 0>

       DBD Turns on all non-DBI flags, in other words, only the ones
           that are specific to DBD::Pg (all those below which start
           with the letters 'pg').

           Outputs the name of each libpq function (without
           arguments) immediately before running it. This is a good
           way to trace the flow of your program at a low level.
           This information is also output if the trace level is set
           to 4 or greater.

           Outputs the name of each internal DBD::Pg function, and
           other information such as the function arguments or
           important global variables, as each function starts. This
           information is also output if the trace level is set to 4
           or greater.

           Outputs a simple message at the very end of each internal
           DBD::Pg function. This is also output if the trace level
           is set to 4 or greater.

           Forces each line of trace output to begin with the string
           "dbdpg: ". This helps to differentiate it from the normal
           DBI trace output.

           Outputs a message showing the connection string right
           before a new database connection is attempted, a message
           when the connection was successful, and a message right
           after the database has been disconnected. Also output if
           trace level is 5 or greater.


       DBD::Pg uses the "func" method to support a variety of
       functions.  Note that the name of the function comes last,
       after the arguments.

             $attrs = $dbh->func($table, 'table_attributes');

           Use of the tables_attributes function is no longer
           recommended. Instead, you can use the more portable
           "column_info" and "primary_key" methods to access the
           same information.

           The table_attributes method returns, for the given table
           argument, a reference to an array of hashes, each of
           which contains the following keys:

             NAME        attribute name
             TYPE        attribute type
             SIZE        attribute size (-1 for variable size)
             NULLABLE    flag nullable
             DEFAULT     default value
             CONSTRAINT  constraint
             PRIMARY_KEY flag is_primary_key
             REMARKS     attribute description

             $lobjId = $dbh->pg_lo_creat($mode);

           Creates a new large object and returns the object-id.
           $mode is a bitmask describing read and write access to
           the new object. This setting is ignored since Postgres
           version 8.1. For backwards compatibility, however, you
           should set a valid mode anyway (see "pg_lo_open" for a
           list of valid modes).

           Upon failure it returns "undef". This function cannot be
           used if AutoCommit is enabled.

           The old way of calling large objects functions is
           deprecated: $dbh->func(.., 'lo_);

             $lobj_fd = $dbh->pg_lo_open($lobjId, $mode);

           Opens an existing large object and returns an object-
           descriptor for use in subsequent "lo_*" calls. $mode is a
           bitmask describing read and write access to the opened
           object. It may be one of:

             $dbh->{pg_INV_READ} | $dbh->{pg_INV_WRITE}

           "pg_INV_WRITE" and "pg_INV_WRITE | pg_INV_READ" modes are
           identical; in both modes, the large object can be read
           from or written to.  Reading from the object will provide
           the object as written in other committed transactions,
           along with any writes performed by the current
           transaction.  Objects opened with "pg_INV_READ" cannot be
           written to. Reading from this object will provide the
           stored data at the time of the transaction snapshot which
           was active when "lo_write" was called.

           Returns "undef" upon failure. Note that 0 is a perfectly
           correct (and common) object descriptor! This function
           cannot be used if AutoCommit is enabled.

             $nbytes = $dbh->pg_lo_write($lobj_fd, $buffer, $len);

           Writes $len bytes of c<$buffer> into the large object
           $lobj_fd. Returns the number of bytes written and "undef"
           upon failure. This function cannot be used if AutoCommit
           is enabled.

             $nbytes = $dbh->pg_lo_read($lobj_fd, $buffer, $len);

           Reads $len bytes into c<$buffer> from large object
           $lobj_fd. Returns the number of bytes read and "undef"
           upon failure. This function cannot be used if AutoCommit
           is enabled.

             $loc = $dbh->pg_lo_lseek($lobj_fd, $offset, $whence);

           Changes the current read or write location on the large
           object $obj_id. Currently $whence can only be 0 (which is
           L_SET). Returns the current location and "undef" upon
           failure. This function cannot be used if AutoCommit is

             $loc = $dbh->pg_lo_tell($lobj_fd);

           Returns the current read or write location on the large
           object $lobj_fd and "undef" upon failure.  This function
           cannot be used if AutoCommit is enabled.

             $lobj_fd = $dbh->pg_lo_close($lobj_fd);

           Closes an existing large object. Returns true upon
           success and false upon failure.  This function cannot be
           used if AutoCommit is enabled.

             $ret = $dbh->pg_lo_unlink($lobjId);

           Deletes an existing large object. Returns true upon
           success and false upon failure.  This function cannot be
           used if AutoCommit is enabled.

             $lobjId = $dbh->pg_lo_import($filename);

           Imports a Unix file as a large object and returns the
           object id of the new object or "undef" upon failure.

             $ret = $dbh->pg_lo_export($lobjId, $filename);

           Exports a large object into a Unix file. Returns false
           upon failure, true otherwise.

             $fd = $dbh->func('getfd');

           Deprecated, use $dbh->{pg_socket} instead.


         $hashref = $dbh->private_attribute_info();
         $hashref = $sth->private_attribute_info();

       Returns a hash of all private attributes used by DBD::Pg, for
       either a database or a statement handle. Currently, all the
       hash values are undef.

       InactiveDestroy (boolean)

       If set to true, then the "disconnect" method will not be
       automatically called when the database handle goes out of
       scope. This is required if you are forking, and even then you
       must tread carefully and ensure that either the parent or the
       child (but not both!) handles all database calls from that
       point forwards, so that messages from the Postgres backend
       are only handled by one of the processes. If you don't set
       things up properly, you will see messages such as "server
       closed the connection unexpectedly", and "message type 0x32
       arrived from server while idle". The best solution is to
       either have the child process reconnect to the database with
       a fresh database handle, or to rewrite your application not
       to use use forking. See the section on "Asynchronous Queries"
       for a way to have your script continue to work while the
       database is processing a request.

       RaiseError (boolean, inherited)

       Forces errors to always raise an exception. Although it
       defaults to off, it is recommended that this be turned on, as
       the alternative is to check the return value of every method
       (prepare, execute, fetch, etc.)  manually, which is easy to
       forget to do.

       PrintError (boolean, inherited)

       Forces database errors to also generate warnings, which can
       then be filtered with methods such as locally redefining
       $SIG{__WARN__} or using modules such as "CGI::Carp". This
       attribute is on by default.

       ShowErrorStatement (boolean, inherited)

       Appends information about the current statement to error
       messages. If placeholder information is available, adds that
       as well. Defaults to false.

       Warn (boolean, inherited)

       Enables warnings. This is on by default, and should only be
       turned off in a local block for a short a time only when
       absolutely needed.

       Executed (boolean, read-only)

       Indicates if a handle has been executed. For database
       handles, this value is true after the "do" method has been
       called, or when one of the child statement handles has issued
       an "execute". Issuing a "commit" or "rollback" always resets
       the attribute to false for database handles. For statement
       handles, any call to "execute" or its variants will flip the
       value to true for the lifetime of the statement handle.

       TraceLevel (integer, inherited)

       Sets the trace level, similar to the "trace" method. See the
       sections on "trace" and "parse_trace_flag" for more details.

       Active (boolean, read-only)

       Indicates if a handle is active or not. For database handles,
       this indicates if the database has been disconnected or not.
       For statement handles, it indicates if all the data has been
       fetched yet or not. Use of this attribute is not encouraged.

       Kids (integer, read-only)

       Returns the number of child processes created for each handle
       type. For a driver handle, indicates the number of database
       handles created. For a database handle, indicates the number
       of statement handles created. For statement handles, it
       always returns zero, because statement handles do not create

       ActiveKids (integer, read-only)

       Same as "Kids", but only returns those that are active.

       CachedKids (hash ref)

       Returns a hashref of handles. If called on a database handle,
       returns all statement handles created by use of the
       "prepare_cached" method. If called on a driver handle,
       returns all database handles created by the "connect_cached"

       ChildHandles (array ref)

       Implemented by DBI, no driver-specific impact.

       PrintWarn (boolean, inherited)

       Implemented by DBI, no driver-specific impact.

       HandleError (boolean, inherited)

       Implemented by DBI, no driver-specific impact.

       HandleSetErr (code ref, inherited)

       Implemented by DBI, no driver-specific impact.

       ErrCount (unsigned integer)

       Implemented by DBI, no driver-specific impact.

       FetchHashKeyName (string, inherited)

       Implemented by DBI, no driver-specific impact.

       ChopBlanks (boolean, inherited)

       Supported by DBD::Pg as proposed by DBI. This method is
       similar to the SQL function "RTRIM".

       Taint (boolean, inherited)

       Implemented by DBI, no driver-specific impact.

       TaintIn (boolean, inherited)

       Implemented by DBI, no driver-specific impact.

       TaintOut (boolean, inherited)

       Implemented by DBI, no driver-specific impact.

       Profile (inherited)

       Implemented by DBI, no driver-specific impact.

       Type (scalar)

       Returns "dr" for a driver handle, "db" for a database handle,
       and "st" for a statement handle.  Should be rarely needed.


       Not used by DBD::Pg


       Not used by DBD::Pg


       Not used by DBD::Pg

   Database Handle Methods

         $ary_ref = $dbh->selectall_arrayref($sql);
         $ary_ref = $dbh->selectall_arrayref($sql, \%attr);
         $ary_ref = $dbh->selectall_arrayref($sql, \%attr, @bind_values);

       Returns a reference to an array containing the rows returned
       by preparing and executing the SQL string.  See the DBI
       documentation for full details.


         $hash_ref = $dbh->selectall_hashref($sql, $key_field);

       Returns a reference to a hash containing the rows returned by
       preparing and executing the SQL string.  See the DBI
       documentation for full details.


         $ary_ref = $dbh->selectcol_arrayref($sql, \%attr, @bind_values);

       Returns a reference to an array containing the first column
       from each rows returned by preparing and executing the SQL
       string. It is possible to specify exactly which columns to
       return. See the DBI documentation for full details.


         $sth = $dbh->prepare($statement, \%attr);

       WARNING: DBD::Pg now (as of version 1.40) uses true prepared
       statements by sending them to the backend to be prepared by
       the Postgres server. Statements that were legal before may no
       longer work. See below for details.

       The prepare method prepares a statement for later execution.
       PostgreSQL supports prepared statements, which enables
       DBD::Pg to only send the query once, and simply send the
       arguments for every subsequent call to "execute".  DBD::Pg
       can use these server-side prepared statements, or it can just
       send the entire query to the server each time. The best way
       is automatically chosen for each query. This will be
       sufficient for most users: keep reading for a more detailed
       explanation and some optional flags.

       Queries that do not begin with the word "SELECT", "INSERT",
       "UPDATE", or "DELETE" are never sent as server-side prepared

       Deciding whether or not to use prepared statements depends on
       many factors, but you can force them to be used or not used
       by using the "pg_server_prepare" attribute when calling
       "prepare". Setting this to "0" means to never use prepared
       statements. Setting "pg_server_prepare" to "1" means that
       prepared statements should be used whenever possible. This is
       the default when connected to Postgres servers version 8.0 or
       higher. Servers that are version 7.4 get a special default
       value of "2", because server-side statements were only
       partially supported in that version. In this case, it only
       uses server-side prepares if all parameters are specifically

       The "pg_server_prepare" attribute can also be set at
       connection time like so:

         $dbh = DBI->connect($DBNAME, $DBUSER, $DBPASS,
                             { AutoCommit => 0,
                               RaiseError => 1,
                               pg_server_prepare => 0,

       or you may set it after your database handle is created:

         $dbh->{pg_server_prepare} = 1;

       To enable it for just one particular statement:

         $sth = $dbh->prepare("SELECT id FROM mytable WHERE val = ?",
                              { pg_server_prepare => 1 });

       You can even toggle between the two as you go:

         $sth->{pg_server_prepare} = 1;
         $sth->{pg_server_prepare} = 0;
         $sth->{pg_server_prepare} = 1;

       In the above example, the first execute will use the
       previously prepared statement.  The second execute will not,
       but will build the query into a single string and send it to
       the server. The third one will act like the first and only
       send the arguments.  Even if you toggle back and forth, a
       statement is only prepared once.

       Using prepared statements is in theory quite a bit faster:
       not only does the PostgreSQL backend only have to prepare the
       query only once, but DBD::Pg no longer has to worry about
       quoting each value before sending it to the server.

       However, there are some drawbacks. The server cannot always
       choose the ideal parse plan because it will not know the
       arguments before hand. But for most situations in which you
       will be executing similar data many times, the default plan
       will probably work out well. Programs such as PgBouncer which
       cache connections at a low level should not use prepared
       statements via DBD::Pg, or must take extra care in the
       application to account for the fact that prepared statements
       are not shared across database connections. Further
       discussion on this subject is beyond the scope of this
       documentation: please consult the pgsql-performance mailing
       list, <>

       Only certain commands will be sent to a server-side prepare:
       currently these include "SELECT", "INSERT", "UPDATE", and
       "DELETE". DBD::Pg uses a simple naming scheme for the
       prepared statements themselves: dbdpg_XY_Z, where Y is the
       current PID, X is either 'p' or 'n' (depending on if the PID
       is a positive or negative number), and Z is a number that
       starts at 1 and increases each time a new statement is
       prepared. This number is tracked at the database handle
       level, so multiple statement handles will not collide.

       You cannot send more than one command at a time in the same
       prepare command (by separating them with semi-colons) when
       using server-side prepares.

       The actual "PREPARE" is usually not performed until the first
       execute is called, due to the fact that information on the
       data types (provided by "bind_param") may be provided after
       the prepare but before the execute.

       A server-side prepare may happen before the first "execute",
       but only if the server can handle the server-side prepare,
       and the statement contains no placeholders. It will also be
       prepared if the "pg_prepare_now" attribute is passed in and
       set to a true value. Similarly, the "pg_prepare_now"
       attribute can be set to 0 to ensure that the statement is not
       prepared immediately, although the cases in which you would
       want this are very rare. Finally, you can set the default
       behavior of all prepare statements by setting the
       "pg_prepare_now" attribute on the database handle:

         $dbh->{pg_prepare_now} = 1;

       The following two examples will be prepared right away:

         $sth->prepare("SELECT 123"); ## no placeholders

         $sth->prepare("SELECT 123, ?", {pg_prepare_now => 1});

       The following two examples will NOT be prepared right away:

         $sth->prepare("SELECT 123, ?"); ## has a placeholder

         $sth->prepare("SELECT 123", {pg_prepare_now => 0});

       There are times when you may want to prepare a statement
       yourself. To do this, simply send the "PREPARE" statement
       directly to the server (e.g. with the "do" method). Create a
       statement handle and set the prepared name via the
       "pg_prepare_name" attribute. The statement handle can be
       created with a dummy statement, as it will not be executed.
       However, it should have the same number of placeholders as
       your prepared statement. Example:

         $dbh->do('PREPARE mystat AS SELECT COUNT(*) FROM pg_class WHERE reltuples < ?');
         $sth = $dbh->prepare('SELECT ?');
         $sth->bind_param(1, 1, SQL_INTEGER);
         $sth->{pg_prepare_name} = 'mystat';

       The above will run the equivalent of this query on the

         EXECUTE mystat(123);

       which is the equivalent of:

         SELECT COUNT(*) FROM pg_class WHERE reltuples < 123;

       You can force DBD::Pg to send your query directly to the
       server by adding the "pg_direct" attribute to your prepare
       call. This is not recommended, but is added just in case you
       need it.


       There are three types of placeholders that can be used in
       DBD::Pg. The first is the "question mark" type, in which each
       placeholder is represented by a single question mark
       character. This is the method recommended by the DBI specs
       and is the most portable. Each question mark is internally
       replaced by a "dollar sign number" in the order in which they
       appear in the query (important when using "bind_param").

       The method second type of placeholder is "dollar sign
       numbers". This is the method that Postgres uses internally
       and is overall probably the best method to use if you do not
       need compatibility with other database systems. DBD::Pg, like
       PostgreSQL, allows the same number to be used more than once
       in the query.  Numbers must start with "1" and increment by
       one value (but can appear in any order within the query). If
       the same number appears more than once in a query, it is
       treated as a single parameter and all instances are replaced
       at once. Examples:

       Not legal:

         $SQL = 'SELECT count(*) FROM pg_class WHERE relpages > $2'; # Does not start with 1

         $SQL = 'SELECT count(*) FROM pg_class WHERE relpages BETWEEN $1 AND $3'; # Missing 2


         $SQL = 'SELECT count(*) FROM pg_class WHERE relpages > $1';

         $SQL = 'SELECT count(*) FROM pg_class WHERE relpages BETWEEN $1 AND $2';

         $SQL = 'SELECT count(*) FROM pg_class WHERE relpages BETWEEN $2 AND $1'; # legal but confusing

         $SQL = 'SELECT count(*) FROM pg_class WHERE relpages BETWEEN $1 AND $2 AND reltuples > $1';

         $SQL = 'SELECT count(*) FROM pg_class WHERE relpages > $1 AND reltuples > $1';

       In the final statement above, DBI thinks there is only one
       placeholder, so this statement will replace both

         $sth->bind_param(1, 2045);

       While a simple execute with no bind_param calls requires only
       a single argument as well:


       The final placeholder type is "named parameters" in the
       format ":foo". While this syntax is supported by DBD::Pg, its
       use is discouraged in favor of dollar-sign numbers.

       The different types of placeholders cannot be mixed within a
       statement, but you may use different ones for each statement
       handle you have. This is confusing at best, so stick to one
       style within your program.

       If your queries use operators that contain question marks
       (e.g. some of the native Postgres geometric operators) or
       array slices (e.g. "data[100:300]"), you can tell DBD::Pg to
       ignore any non-dollar sign placeholders by setting the
       "pg_placeholder_dollaronly" attribute at either the database
       handle or the statement handle level. Examples:

         $dbh->{pg_placeholder_dollaronly} = 1;
         $sth = $dbh->prepare(q{SELECT * FROM mytable WHERE lseg1 ?# lseg2 AND name = $1});

       Alternatively, you can set it at prepare time:

         $sth = $dbh->prepare(q{SELECT * FROM mytable WHERE lseg1 ?-| lseg2 AND name = $1},
           {pg_placeholder_dollaronly = 1});


         $sth = $dbh->prepare_cached($statement, \%attr);

       Implemented by DBI, no driver-specific impact. This method is
       most useful when using a server that supports server-side
       prepares, and you have asked the prepare to happen
       immediately via the "pg_prepare_now" attribute.


         $rv = $dbh->do($statement);
         $rv = $dbh->do($statement, \%attr);
         $rv = $dbh->do($statement, \%attr, @bind_values);

       Prepare and execute a single statement. Returns the number of
       rows affected if the query was successful, returns undef if
       an error occurred, and returns -1 if the number of rows is
       unknown or not available. Note that this method will return
       0E0 instead of 0 for 'no rows were affected', in order to
       always return a true value if no error occurred.

       If neither "\%attr" nor @bind_values is given, the query will
       be sent directly to the server without the overhead of
       internally creating a statement handle and running prepare
       and execute, for a measurable speed increase.

       Note that an empty statement (a string with no length) will
       not be passed to the server; if you want a simple test, use
       "SELECT 123" or the "ping" method.


         $rv = $dbh->last_insert_id(undef, $schema, $table, undef);
         $rv = $dbh->last_insert_id(undef, $schema, $table, undef, {sequence => $seqname});

       Attempts to return the id of the last value to be inserted
       into a table.  You can either provide a sequence name
       (preferred) or provide a table name with optional schema, and
       DBD::Pg will attempt to find the sequence itself.  The
       current value of the sequence is returned by a call to the
       "CURRVAL()" PostgreSQL function. This will fail if the
       sequence has not yet been used in the current database

       If you do not know the name of the sequence, you can provide
       a table name and DBD::Pg will attempt to return the correct
       value. To do this, there must be at least one column in the
       table with a "NOT NULL" constraint, that has a unique
       constraint, and which uses a sequence as a default value. If
       more than one column meets these conditions, the primary key
       will be used. This involves some looking up of things in the
       system table, so DBD::Pg will cache the sequence name for
       subsequent calls. If you need to disable this caching for
       some reason, (such as the sequence name changing), you can
       control it by adding "pg_cache =" 0> to the final (hashref)
       argument for last_insert_id.

       Please keep in mind that this method is far from foolproof,
       so make your script use it properly. Specifically, make sure
       that it is called immediately after the insert, and that the
       insert does not add a value to the column that is using the
       sequence as a default value. However, because we are using
       sequences, you can be sure that the value you got back has
       not been used by any other process.

       Some examples:

         $dbh->do('CREATE SEQUENCE lii_seq START 1');
         $dbh->do(q{CREATE TABLE lii (
           foobar INTEGER NOT NULL UNIQUE DEFAULT nextval('lii_seq'),
           baz VARCHAR)});
         $SQL = 'INSERT INTO lii(baz) VALUES (?)';
         $sth = $dbh->prepare($SQL);
         for (qw(uno dos tres cuatro)) {
           my $newid = $dbh->last_insert_id(undef,undef,undef,undef,{sequence=>'lii_seq'});
           print "Last insert id was $newid\n";

       If you did not want to worry about the sequence name:

         $dbh->do('CREATE TABLE lii2 (
           foobar SERIAL UNIQUE,
           baz VARCHAR)');
         $SQL = 'INSERT INTO lii2(baz) VALUES (?)';
         $sth = $dbh->prepare($SQL);
         for (qw(uno dos tres cuatro)) {
           my $newid = $dbh->last_insert_id(undef,undef,"lii2",undef);
           print "Last insert id was $newid\n";


         $rv = $dbh->commit;

       Issues a COMMIT to the server, indicating that the current
       transaction is finished and that all changes made will be
       visible to other processes. If AutoCommit is enabled, then a
       warning is given and no COMMIT is issued. Returns true on
       success, false on error.  See also the the section on


         $rv = $dbh->rollback;

       Issues a ROLLBACK to the server, which discards any changes
       made in the current transaction. If AutoCommit is enabled,
       then a warning is given and no ROLLBACK is issued. Returns
       true on success, and false on error. See also the the section
       on "Transactions".


       This method turns on transactions until the next call to
       "commit" or "rollback", if "AutoCommit" is currently enabled.
       If it is not enabled, calling begin_work will issue an error.
       Note that the transaction will not actually begin until the
       first statement after begin_work is called.  Example:

         $dbh->{AutoCommit} = 1;
         $dbh->do('INSERT INTO foo VALUES (123)'); ## Changes committed immediately
         ## Not in a transaction yet, but AutoCommit is set to 0

         $dbh->do("INSERT INTO foo VALUES (345)");
         ## DBD::PG actually issues two statements here:
         ## BEGIN;
         ## INSERT INTO foo VALUES (345)
         ## We are now in a transaction

         ## AutoCommit is now set to 1 again


         $rv = $dbh->disconnect;

       Disconnects from the Postgres database. Any uncommitted
       changes will be rolled back upon disconnection. It's good
       policy to always explicitly call commit or rollback at some
       point before disconnecting, rather than relying on the
       default rollback behavior.

       This method may give warnings about "disconnect invalidates X
       active statement handle(s)". This means that you called
       "$sth->execute()" but did not finish fetching all the rows
       from them. To avoid seeing this warning, either fetch all the
       rows or call "$sth->finish()" for each executed statement

       If the script exits before disconnect is called (or, more
       precisely, if the database handle is no longer referenced by
       anything), then the database handle's DESTROY method will
       call the rollback() and disconnect() methods automatically.
       It is best to explicitly disconnect rather than rely on this


         $rv = $dbh->quote($value, $data_type);

       This module implements its own "quote" method. For simple
       string types, both backslashes and single quotes are doubled.
       You may also quote arrayrefs and receive a string suitable
       for passing into Postgres array columns.

       If the value contains backslashes, and the server is version
       8.1 or higher, then the escaped string syntax will be used
       (which places a capital E before the first single quote).
       This syntax is always used when quoting bytea values on
       servers 8.1 and higher.

       The "data_type" argument is optional and should be one of the
       type constants exported by DBD::Pg (such as PG_BYTEA). In
       addition to string, bytea, char, bool, and other standard
       types, the following geometric types are supported: point,
       line, lseg, box, path, polygon, and circle (PG_POINT,

       NOTE: The undocumented (and invalid) support for the
       "SQL_BINARY" data type is officially deprecated. Use
       "PG_BYTEA" with "bind_param()" instead:

         $rv = $sth->bind_param($param_num, $bind_value,
                                { pg_type => PG_BYTEA });


         $string = $dbh->quote_identifier( $name );
         $string = $dbh->quote_identifier( undef, $schema, $table);

       Returns a quoted version of the supplied string, which is
       commonly a schema, table, or column name. The three argument
       form will return the schema and the table together, separated
       by a dot. Examples:

         print $dbh->quote_identifier('grapefruit'); ## Prints: "grapefruit"

         print $dbh->quote_identifier('juicy fruit'); ## Prints: "juicy fruit"

         print $dbh->quote_identifier(undef, 'public', 'pg_proc');
         ## Prints: "public"."pg_proc"


         $ret = $dbh->pg_notifies;

       Looks for any asynchronous notifications received and returns
       either "undef" or a reference to a three-element array
       consisting of an event name, the PID of the backend that sent
       the NOTIFY command, and the optional payload string.  Note
       that this does not check if the connection to the database is
       still valid first - for that, use the c<ping> method. You may
       need to commit if not in autocommit mode - new notices will
       not be picked up while in the middle of a transaction. An

         $dbh->do("LISTEN abc");
         $dbh->do("LISTEN def");

         ## Hang around until we get the message we want
         LISTENLOOP: {
           while (my $notify = $dbh->pg_notifies) {
             my ($name, $pid, $payload) = @$notify;
             print qq{I received notice "$name" from PID $pid, payload was "$payload"\n};
             ## Do something based on the notice received
           $dbh->ping() or die qq{Ping failed!};

       Payloads will always be an empty string unless you are
       connecting to a Postgres server version 8.5 or higher.


         $rv = $dbh->ping;

       This "ping" method is used to check the validity of a
       database handle. The value returned is either 0, indicating
       that the connection is no longer valid, or a positive
       integer, indicating the following:

         Value    Meaning
           1      Database is idle (not in a transaction)
           2      Database is active, there is a command in progress (usually seen after a COPY command)
           3      Database is idle within a transaction
           4      Database is idle, within a failed transaction

       Additional information on why a handle is not valid can be
       obtained by using the "pg_ping" method.


         $rv = $dbh->pg_ping;

       This is a DBD::Pg-specific extension to the "ping" method.
       This will check the validity of a database handle in exactly
       the same way as "ping", but instead of returning a 0 for an
       invalid connection, it will return a negative number. So in
       addition to returning the positive numbers documented for
       "ping", it may also return the following:

         Value    Meaning
          -1      There is no connection to the database at all (e.g. after C<disconnect>)
          -2      An unknown transaction status was returned (e.g. after forking)
          -3      The handle exists, but no data was returned from a test query.

       In practice, you should only ever see -1 and -2.


         $value = $dbh->get_info($info_type);

       Supports a very large set (> 250) of the information types,
       including the minimum recommended by DBI.


         $sth = $dbh->table_info(undef, $schema, $table, $type);

       Returns all tables and views visible to the current user.
       The schema and table arguments will do a "LIKE" search if a
       percent sign ("%") or an underscore ("_") is detected in the
       argument. The $type argument accepts a value of either
       "TABLE" or "VIEW" (using both is the default action). Note
       that a statement handle is returned, and not a direct list of
       tables. See the examples below for ways to handle this.

       The following fields are returned:

       TABLE_CAT: Always NULL, as Postgres does not have the concept
       of catalogs.

       TABLE_SCHEM: The name of the schema that the table or view is

       TABLE_NAME: The name of the table or view.

       TABLE_TYPE: The type of object returned. Will be one of
       "TABLE", "VIEW", or "SYSTEM TABLE".

       The TABLE_SCHEM and TABLE_NAME will be quoted via

       Two additional fields specific to DBD::Pg are returned:

       pg_schema: the unquoted name of the schema

       pg_table: the unquoted name of the table

       If your database supports tablespaces (version 8.0 or
       greater), two additional DBD::Pg specific fields are

       pg_tablespace_name: the name of the tablespace the table is

       pg_tablespace_location: the location of the tablespace the
       table is in

       Tables that have not been assigned to a particular tablespace
       (or views) will return NULL ("undef") for both of the above

       Rows are returned alphabetically, with all tables first, and
       then all views.

       Examples of use:

         ## Display all tables and views in the public schema:
         $sth = $dbh->table_info('', 'public', undef, undef);
         for my $rel (@{$sth->fetchall_arrayref({})}) {
           print "$rel->{TABLE_TYPE} name is $rel->{TABLE_NAME}\n";

         # Display the schema of all tables named 'foo':
         $sth = $dbh->table_info('', undef, 'foo', 'TABLE');
         for my $rel (@{$sth->fetchall_arrayref({})}) {
           print "Table name is $rel->{TABLE_SCHEM}.$rel->{TABLE_NAME}\n";


         $sth = $dbh->column_info( undef, $schema, $table, $column );

       Supported by this driver as proposed by DBI with the follow
       exceptions.  These fields are currently always returned with
       NULL ("undef") values:


       Also, six additional non-standard fields are returned:

       pg_type: data type with additional info i.e. "character

       pg_constraint: holds column constraint definition

       pg_schema: the unquoted name of the schema

       pg_table: the unquoted name of the table

       pg_column: the unquoted name of the column

       pg_enum_values: an array reference of allowed values for an
       enum column

       Note that the TABLE_SCHEM, TABLE_NAME, and COLUMN_NAME fields
       all return output wrapped in quote_ident(). If you need the
       unquoted version, use the pg_ fields above.


         $sth = $dbh->primary_key_info( undef, $schema, $table, \%attr );

       Supported by this driver as proposed by DBI. There are no
       search patterns allowed, but leaving the $schema argument
       blank will cause the first table found in the schema search
       path to be used. An additional field, "DATA_TYPE", is
       returned and shows the data type for each of the arguments in
       the "COLUMN_NAME" field.

       This method will also return tablespace information for
       servers that support tablespaces. See the "table_info" entry
       for more information.

       The five additional custom fields returned are:

       pg_tablespace_name: name of the tablespace, if any

       pg_tablespace_location: location of the tablespace

       pg_schema: the unquoted name of the schema

       pg_table: the unquoted name of the table

       pg_column: the unquoted name of the column

       In addition to the standard format of returning one row for
       each column found for the primary key, you can pass the
       "pg_onerow" attribute to force a single row to be used. If
       the primary key has multiple columns, the "KEY_SEQ",
       "COLUMN_NAME", and "DATA_TYPE" fields will return a comma-
       delimited string. If the "pg_onerow" attribute is set to "2",
       the fields will be returned as an arrayref, which can be
       useful when multiple columns are involved:

         $sth = $dbh->primary_key_info('', '', 'dbd_pg_test', {pg_onerow => 2});
         if (defined $sth) {
           my $pk = $sth->fetchall_arrayref()->[0];
           print "Table $pk->[2] has a primary key on these columns:\n";
           for (my $x=0; defined $pk->[3][$x]; $x++) {
             print "Column: $pk->[3][$x]  (data type: $pk->[6][$x])\n";


         @key_column_names = $dbh->primary_key(undef, $schema, $table);

       Simple interface to the "primary_key_info" method. Returns a
       list of the column names that comprise the primary key of the
       specified table. The list is in primary key column sequence
       order. If there is no primary key then an empty list is


         $sth = $dbh->foreign_key_info( $pk_catalog, $pk_schema, $pk_table,
                                        $fk_catalog, $fk_schema, $fk_table );

       Supported by this driver as proposed by DBI, using the
       SQL/CLI variant.  There are no search patterns allowed, but
       leaving the $schema argument blank will cause the first table
       found in the schema search path to be used. Two additional
       fields, "UK_DATA_TYPE" and "FK_DATA_TYPE", are returned to
       show the data type for the unique and foreign key columns.
       Foreign keys that have no named constraint (where the
       referenced column only has an unique index) will return
       "undef" for the "UK_NAME" field.


         $sth = $dbh->statistics_info( undef, $schema, $table, $unique_only, $quick );

       Returns a statement handle that can be fetched from to give
       statistics information on a specific table and its indexes.
       The $table argument is mandatory. The $schema argument is
       optional but recommended. The $unique_only argument, if true,
       causes only information about unique indexes to be returned.
       The $quick argument is not used by DBD::Pg. For information
       on the format of the rows returned, please see the DBI


         @names = $dbh->tables( undef, $schema, $table, $type, \%attr );

       Supported by this driver as proposed by DBI. This method
       returns all tables and/or views which are visible to the
       current user: see "table_info" for more information about the
       arguments. The name of the schema appears before the table or
       view name. This can be turned off by adding in the
       "pg_noprefix" attribute:

         my @tables = $dbh->tables( '', '', 'dbd_pg_test', '', {pg_noprefix => 1} );


         $type_info_all = $dbh->type_info_all;

       Supported by this driver as proposed by DBI. Information is
       only provided for SQL datatypes and for frequently used
       datatypes. The mapping between the PostgreSQL typename and
       the SQL92 datatype (if possible) has been done according to
       the following table:

         | typname       | SQL92                              |
         | bool          | BOOL                               |
         | text          | /                                  |
         | bpchar        | CHAR(n)                            |
         | varchar       | VARCHAR(n)                         |
         | int2          | SMALLINT                           |
         | int4          | INT                                |
         | int8          | /                                  |
         | money         | /                                  |
         | float4        | FLOAT(p)   p<7=float4, p<16=float8 |
         | float8        | REAL                               |
         | abstime       | /                                  |
         | reltime       | /                                  |
         | tinterval     | /                                  |
         | date          | /                                  |
         | time          | /                                  |
         | datetime      | /                                  |
         | timespan      | TINTERVAL                          |
         | timestamp     | TIMESTAMP                          |


         @type_info = $dbh->type_info($data_type);

       Returns a list of hash references holding information about
       one or more variants of $data_type.  See the DBI
       documentation for more details.



       Writes debugging information from the PostgreSQL backend to a
       file. This is not related to the DBI "trace" method and you
       should not use this method unless you know what you are
       doing. If you do enable this, be aware that the file will
       grow very large, very quick. To stop logging to the file, use
       the "pg_server_untrace" method. The first argument must be a
       file handle, not a filename. Example:

         my $pid = $dbh->{pg_pid};
         my $file = "pgbackend.$pid.debug.log";
         open(my $fh, ">$file") or die qq{Could not open "$file": $!\n};
         ## Run code you want to trace here



       Stop server logging to a previously opened file.


         @row_ary = $dbh->selectrow_array($sql);
         @row_ary = $dbh->selectrow_array($sql, \%attr);
         @row_ary = $dbh->selectrow_array($sql, \%attr, @bind_values);

       Returns an array of row information after preparing and
       executing the provided SQL string. The rows are returned by
       calling "fetchrow_array". The string can also be a statement
       handle generated by a previous prepare. Note that only the
       first row of data is returned. If called in a scalar context,
       only the first column of the first row is returned. Because
       this is not portable, it is not recommended that you use this
       method in that way.


         $ary_ref = $dbh->selectrow_arrayref($statement);
         $ary_ref = $dbh->selectrow_arrayref($statement, \%attr);
         $ary_ref = $dbh->selectrow_arrayref($statement, \%attr, @bind_values);

       Exactly the same as "selectrow_array", except that it returns
       a reference to an array, by internal use of the
       "fetchrow_arrayref" method.


         $hash_ref = $dbh->selectrow_hashref($sql);
         $hash_ref = $dbh->selectrow_hashref($sql, \%attr);
         $hash_ref = $dbh->selectrow_hashref($sql, \%attr, @bind_values);

       Exactly the same as "selectrow_array", except that it returns
       a reference to an hash, by internal use of the
       "fetchrow_hashref" method.


         $other_dbh = $dbh->clone();

       Creates a copy of the database handle by connecting with the
       same parameters as the original handle, then trying to merge
       the attributes. See the DBI documentation for complete usage.

   Database Handle Attributes
       AutoCommit (boolean)

       Supported by DBD::Pg as proposed by DBI. According to the
       classification of DBI, PostgreSQL is a database in which a
       transaction must be explicitly started. Without starting a
       transaction, every change to the database becomes immediately
       permanent. The default of AutoCommit is on, but this may
       change in the future, so it is highly recommended that you
       explicitly set it when calling "connect". For details see the
       notes about "Transactions" elsewhere in this document.

       pg_bool_tf (boolean)

       DBD::Pg specific attribute. If true, boolean values will be
       returned as the characters 't' and 'f' instead of '1' and

       ReadOnly (boolean)

       $dbh->{ReadOnly} = 1;

       Specifies if the current database connection should be in
       read-only mode or not.  In this mode, changes that change the
       database are not allowed and will throw an error. Note: this
       method will not work if "AutoCommit" is true. The read-only
       effect is accomplished by sending a SET TRANSACTION READ ONLY
       after every begin. For more details, please see:

       Please not that this method is not foolproof: there are still
       ways to update the database. Consider this a safety net to
       catch applications that should not be issuing commands such
       as INSERT, UPDATE, or DELETE.

       This method method requires DBI version 1.55 or better.

       pg_server_prepare (integer)

       DBD::Pg specific attribute. Indicates if DBD::Pg should
       attempt to use server-side prepared statements. The default
       value, 1, indicates that prepared statements should be used
       whenever possible. See the section on the "prepare" method
       for more information.

       pg_placeholder_dollaronly (boolean)

       DBD::Pg specific attribute. Defaults to false. When true,
       question marks inside of statements are not treated as
       placeholders. Useful for statements that contain unquoted
       question marks, such as geometric operators.

       pg_enable_utf8 (boolean)

       DBD::Pg specific attribute. If true, then the "utf8" flag
       will be turned on for returned character data (if the data is
       valid UTF-8). For details about the "utf8" flag, see the
       "Encode" module. This attribute is only relevant under perl
       5.8 and later.

       pg_errorlevel (integer)

       DBD::Pg specific attribute. Sets the amount of information
       returned by the server's error messages. Valid entries are 0,
       1, and 2. Any other number will be forced to the default
       value of 1.

       A value of 0 ("TERSE") will show severity, primary text, and
       position only and will usually fit on a single line. A value
       of 1 ("DEFAULT") will also show any detail, hint, or context
       fields. A value of 2 ("VERBOSE") will show all available

       pg_lib_version (integer, read-only)

       DBD::Pg specific attribute. Indicates which version of
       PostgreSQL that DBD::Pg was compiled against. In other words,
       which libraries were used.  Returns a number with major,
       minor, and revision together; version 8.1.4 would be returned
       as 80104.

       pg_server_version (integer, read-only)

       DBD::Pg specific attribute. Indicates which version of
       PostgreSQL that the current database handle is connected to.
       Returns a number with major, minor, and revision together;
       version 8.0.1 would be 80001.

       Name (string, read-only)

       Returns the name of the current database. This is the same as
       the DSN, without the "dbi:Pg:" part. Before version 2.0.0,
       this only returned the bare database name (e.g. 'foo'). From
       version 2.0.0 onwards, it returns the more correct output
       (e.g. 'dbname=foo')

       Username (string, read-only)

       Returns the name of the user connected to the database.

       pg_db (string, read-only)

       DBD::Pg specific attribute. Returns the name of the current

       pg_user (string, read-only)

       DBD::Pg specific attribute. Returns the name of the user that
       connected to the server.

       pg_host (string, read-only)

       DBD::Pg specific attribute. Returns the host of the current
       server connection. Locally connected hosts will return an
       empty string.

       pg_port (integer, read-only)

       DBD::Pg specific attribute. Returns the port of the
       connection to the server.

       pg_socket (integer, read-only)

       DBD::Pg specific attribute. Returns the file description
       number of the connection socket to the server.

       pg_pass (string, read-only)

       DBD::Pg specific attribute. Returns the password used to
       connect to the server.

       pg_options (string, read-only)

       DBD::Pg specific attribute. Returns the command-line options
       passed to the server. May be an empty string.

       pg_default_port (integer, read-only)

       DBD::Pg specific attribute. Returns the default port used if
       none is specifically given.

       pg_pid (integer, read-only)

       DBD::Pg specific attribute. Returns the process id (PID) of
       the backend server process handling the connection.

       pg_prepare_now (boolean)

       DBD::Pg specific attribute. Default is off. If true, then the
       "prepare" method will immediately prepare commands, rather
       than waiting until the first execute.

       pg_expand_array (boolean)

       DBD::Pg specific attribute. Defaults to true. If false,
       arrays returned from the server will not be changed into a
       Perl arrayref, but remain as a string.

       pg_async_status (integer, read-only)

       DBD::Pg specific attribute. Returns the current status of an
       asynchronous command. 0 indicates no asynchronous command is
       in progress, 1 indicates that an asynchronous command has
       started and -1 indicated that an asynchronous command has
       been cancelled.

       pg_standard_conforming_strings (boolean, read-only)

       DBD::Pg specific attribute. Returns true if the server is
       currently using standard conforming strings. Only available
       if the target server is version 8.2 or better.

       pg_INV_READ (integer, read-only)

       Constant to be used for the mode in "lo_creat" and "lo_open".

       pg_INV_WRITE (integer, read-only)

       Constant to be used for the mode in "lo_creat" and "lo_open".

       Driver (handle, read-only)

       Holds the handle of the parent driver. The only recommended
       use for this is to find the name of the driver using:

Results 1 - 1 of 1
Help - FTP Sites List - Software Dir.
Search over 15 billion files
© 1997-2017