# doc-cache created by Octave 4.0.3
# name: cache
# type: cell
# rows: 3
# columns: 5
# name: <cell-element>
# type: sq_string
# elements: 1
# length: 9
getdbopts


# name: <cell-element>
# type: sq_string
# elements: 1
# length: 370
 -- Function File:  getdbopts (OPTIONS, PARNAME)
 -- Function File:  getdbopts (OPTIONS, PARNAME, DEFAULT)
     Return a specific setting from a structure created by `setdbopts'.
     If PARNAME is not a field of the OPTIONS structure, return DEFAULT
     if supplied, otherwise return an empty matrix.

     (This function uses the code of Octaves 'optimget' function.)


# name: <cell-element>
# type: sq_string
# elements: 1
# length: 66
Return a specific setting from a structure created by `setdbopts'.



# name: <cell-element>
# type: sq_string
# elements: 1
# length: 10
pq_connect


# name: <cell-element>
# type: sq_string
# elements: 1
# length: 1853
 -- Function File: CONNECTION = pq_connect (SETTINGS)
     Establishes a connection to a postgresql server according to
     SETTINGS and returns an `octave_pq_connection' object CONNECTION
     which can be passed to other functions of the package. There can
     be multiple connections. An `octave_pq_connection' object contains
     information on a connection and will be internally altered by the
     packages functions even though it is only passed as an argument,
     i.e. Octaves 'pass by value' semantics are not adhered to in this
     case.

     SETTINGS can be set by `setdbopts' (copied from Octaves
     `optimset') and can contain (defaults depend on Postgresql):
     `host' (hostname), `hostaddr' (numeric host address), `port' (port
     to connect to), `dbname' (database to connect to), `user' (user
     name to connect as), `password', `connect_timeout', `options'
     (command-line options to send to the server at run-time, see
     Postgresql documentation), `sslmode' (`disable', `allow', `prefer',
     `require', `verify-ca', or `verify-full'; see Postgresql
     documentation of SSL support), `sslcert' (file name of client SSL
     certificate), `sslkey' (location of secret key for client
     certificate, file name or external OpenSSL engine (colon-separated
     engine name and an engine-specific key identifier)), `sslrootcert'
     (file name of root SSL certificate), `sslcrl' (file name of SSL
     certificate revocation list), `krbsrvname' (kerberos service
     name), `service' (service name in pq_service.conf to use for
     additional parameters).

     All these settings are passed to the server as they are, so it may
     be better to consult the postgresql documentation for them, e.g.
     the documentation of the PQconnectdb function in libpq.

     See also: pq_exec_params, pq_update_types.



# name: <cell-element>
# type: sq_string
# elements: 1
# length: 80
Establishes a connection to a postgresql server according to SETTINGS
and return



# name: <cell-element>
# type: sq_string
# elements: 1
# length: 14
pq_exec_params


# name: <cell-element>
# type: sq_string
# elements: 1
# length: 11253
 -- Function File: pq_exec_params (CONNECTION, COMMAND)
 -- Loadable Function: pq_exec_params (CONNECTION, COMMAND, PARAMS)
 -- Loadable Function: pq_exec_params (CONNECTION, COMMAND, SETTINGS)
 -- Loadable Function: pq_exec_params (CONNECTION, COMMAND, PARAMS,
          SETTINGS)
     Sends the string COMMAND, which must contain a single SQL command,
     over the connection CONNECTION. Parameters in COMMAND can be
     replaced by $1, $2, etc and their values given in the
     one-dimensional cell-array PARAMS. Parameters of composite type
     sent this way must have their type defined in the database. For
     typeconversions, the package maintains a notion of defined types,
     which should be refreshed with `pq_update_types' if types are
     defined or dropped after establishing the connection, or if the
     schema search path changes. SETTINGS is a structure of settings,
     it can be created by `setdbopts'.

     Settings currently understood by `pq_exec_params':

    `param_types'
          One-dimensional cell-array with type specifications for
          parameters in PARAMS. If present, must have the same length
          as PARAMS.  Entries may be empty if no specification is
          necessary (see below).  Type specifications are strings
          corresponding to the entries returned by `SELECT typname FROM
          pg_type WHERE typarray != 0 OR typtype = 'c';', optionally
          having `[]' appended (without space) to indicate an array.
          Type specifications can be schema-qualified, otherwise they
          refer to the visible type with that name.

    `copy_in_path, copy_out_path'
          Path to files at the client side for `copy from stdin' and
          `copy to stdout', respectively.

    `copy_in_from_variable'
          Logical scalar, default `false'. If `true', `copy from stdin'
          uses data from an Octave variable instead of from a file.

    `copy_in_data'
          2-dimensional cell-array with columns of suitable type (see
          below) - will be used instead of a file as data for `copy
          from stdin' if `copy_in_from_variable' is `true'.

    `copy_in_types'
          If some columns in `copy_in_data' need a type specification
          (see below), `copy_in_types' has to be set to a cell-array
          with type specifications, with an entry (possibly empty) for
          each column.

    `copy_in_with_oids'
          If you want to copy in with oids when using data from an
          Octave variable, the first column of the data must contain
          the OIDs and `copy_in_with_oids' has to be set to `true'
          (default `false'); `with oids' should be specified together
          with `copy from stdin' in the command, otherwise Postgresql
          will ignore the copied oids.

     There is no way to `copy to stdout' into an Octave variable, but a
     `select' command can be used for this purpose.

     For queries (commands potentially returning data), the output will
     be a structure with fields `data' (containing a cell array with the
     data, columns correspond to returned database columns, rows
     correspond to returned tuples), `columns' (containing the column
     headers), and `types' (a  structure-vector with the postgresql
     data types of the columns, subfields `name' (string with
     typename), `is_array' (boolean), `is_composite' (boolean),
     `is_enum' (boolean), and `elements' (if `is_composite == true',
     structure-vector of element types, containing fields corresponding
     to those of `types')). For copy commands nothing is returned. For
     other commands, the output will be the number of affected rows in
     the database.

     Mapping of currently implemented Postgresql types to Octave types

     The last column indicates whether specification of type (see above)
     is necessary for conversion from Octave type to Postgresql type,
     i.e.  if Postgresql type is not deduced from the type of the Octave
     variable. As long as the Postgresql type is deduced correctly or is
     user-specified, it is often sufficent to provide an Octave type
     that can be converted to the Octave type given in the table.

     Postgresql   Octave                                 Spec.
     ------------------------------------------------------------ 
     bool         logical scalar                         no
     oid          uint32 scalar                          no
     float8       double scalar                          no
     float4       single scalar                          no
     text         string                                 no
     varchar      string                                 yes
     bpchar       string                                 yes
     name         string of length < `NAMEDATALEN'       yes
                  (often 64)                             
     bytea        array of uint8, one-dimensional if     no
                  converted from postgresql data         
     int2         int16 scalar                           no
     int4         int32 scalar                           no
     int8         int64 scalar                           no
     money        int64 scalar, which is 100 times the   yes
                  currency value to enable storing the   
                  'small currency' (e.g. Cent) fraction  
                  in the last two digits                 
     timestamp    8-byte-time-value (see below),         yes
                  positive or negative difference to     
                  2000-01-01 00:00                       
     timestamptz  as timestamp                           yes
     time         8-byte-time-value (see below)          yes
     timetz       2-element cell array with              yes
                  8-byte-time-value (see below, time of  
                  day) and int32 scalar (time zone in    
                  seconds, negative east of UTC)         
     date         int32 scalar, positive or negative     yes
                  difference to 2000-01-01               
     interval     3-element cell array with              yes
                  8-byte-time-value (see below), int32   
                  (days), and int32 (months)             
     point        geometric point data for one point     no
                  (see below)                            
     lseg         geometric point data for two points    no
                  (see below)                            
     line (not    as lseg                                yes
     yet                                                 
     implemented                                         
     by                                                  
     postgresql-9.2.4)                                       
     box          as lseg                                yes
     circle       real vector (but the restrictions for  no
                  type uint8 as in geometric element     
                  type apply, as explained below) with   
                  3 elements, no. 1 and 2 centre         
                  coordinates, no. 3 radius              
     polygon      geometric point data (see below)       yes
     path         structure with fields `closed'         yes
                  (boolean, is path closed?)  and        
                  `path' (geometric point data, see      
                  below).                                
     inet         uint8 array of 4 or 5 elements for     yes
                  IPv4 or uint16 array of 8 or 9         
                  elements for IPv6. 5th or 9th          
                  element, respectively, contain number  
                  of set bits in network mask, the       
                  default (if there are only 4 or 8      
                  elements, respectively) is all bits    
                  set.                                   
     cidr         as inet                                yes
     macaddr      uint8 array of 6 elements              yes
     bit          structure with fields `bitlen'         yes
                  (int32, number of valid bits) and      
                  `bits' (uint8 array, 8 bits per        
                  entry, first entry contains the        
                  leftmost bits, last entry may contain  
                  less than 8 bits)                      
     varbit       as bit yes                             
     uuid         uint8 array of 16 elements             yes
     xml          string                                 yes
     any array    Structure with fields `data' (holding  yes
                  a cell-array with entries of a type    
                  corresponding to the Postgresql        
                  element type), `ndims' (holding the    
                  number of dimensions of the            
                  corresponding Postgresql array, since  
                  this can not be deduced from the       
                  dimensions of the Octave cell-array    
                  in all cases), and optionally (but     
                  always present in returned values)     
                  `lbounds' (a row vector of             
                  enumeration bases for all dimensions,  
                  default is `ones (1, ndims)', see      
                  Postgresql documentation). Array       
                  elements may not correspond to arrays  
                  in Postgresql (use additional          
                  dimensions for this), but may          
                  correspond to composite types, which   
                  is allowed to lead to arbitrarily      
                  deep nesting.                          
     any          One-dimensional cell-array with        yes
     composite    entries of types corresponding to the  
     type         respective Postgresql types. Entries   
                  may also correspond to an array-type   
                  or composite type; this is allowed to  
                  lead to arbitrarily deep nesting.      
     any enum     string                                 yes
     type                                                

     8-byte-time-value: int64 scalar, representing microseconds, if
     server is configured for integer date/time; double scalar,
     representing seconds, if server is configured for float date/time
     (deprecated).  There is no automatic conversion from an octave
     variable, an error is thrown if the wrong of both types is
     supplied. One can use `pq_conninfo' to query the respective server
     configuration.

     geometric point data: any real array (but if of type uint8, the
     geometric type name must always be specified, for otherwise uint8
     would be considered as bytea) with even number of elements. Two
     adjacent elements (adjacent if indexed with a single index) define
     a pair of 2D point coordinates. In converting from postgresql data,
     dimensions of Octave geometric point data will be chosen to be (2,
     n_points) and elements will be of format double.

     Octaves `NA' corresponds to a Postgresql NULL value (not `NaN',
     which is interpreted as a value of a float type!).

     See also: pq_update_types, pq_conninfo.



# name: <cell-element>
# type: sq_string
# elements: 1
# length: 80
Sends the string COMMAND, which must contain a single SQL command, over
the conn



# name: <cell-element>
# type: sq_string
# elements: 1
# length: 10
pq_lo_view


# name: <cell-element>
# type: sq_string
# elements: 1
# length: 341
 -- Function File: pq_lo_view (CONNECTION, OID, VIEWER)
     Exports the large object of Oid OID in the database associated
     with CONNECTION to a temporary file and starts the program VIEWER
     in the background with the name of the temporary file as argument.

     The temporary file will be removed after termination of the viewer.



# name: <cell-element>
# type: sq_string
# elements: 1
# length: 80
Exports the large object of Oid OID in the database associated with
CONNECTION t



# name: <cell-element>
# type: sq_string
# elements: 1
# length: 9
setdbopts


# name: <cell-element>
# type: sq_string
# elements: 1
# length: 360
 -- Function File:  setdbopts ()
 -- Function File:  setdbopts (PAR, VAL, ...)
 -- Function File:  setdbopts (OLD, PAR, VAL, ...)
 -- Function File:  setdbopts (OLD, NEW)
     Create settings structure for database functions.

     Please see individual database functions for valid settings.

     (This function uses the code of Octaves 'optimset' function.)


# name: <cell-element>
# type: sq_string
# elements: 1
# length: 49
Create settings structure for database functions.





