← Back to branch summary

~ubuntu-branches/ubuntu/precise/libpgjava/precise

« back to all changes in this revision

Viewing changes to doc/pgjdbc.xml

  • Committer: Bazaar Package Importer
  • Author(s): Michael Koch
  • Date: 2008-04-26 22:01:11 UTC
  • mfrom: (3.1.4 gutsy)
  • Revision ID: james.westby@ubuntu.com-20080426220111-yasgxtas5smx2qm3
Tags: 8.2-504-2
http://bugs.debian.org/398348
http://bugs.debian.org/477557
* Updated description to mention PostgreSQL 8.3 as supported.
  Closes: #398348
* Removed libpgjava transitional package. Closes: #477557
* Moved debhelper and cdbs from Build-Depends-Indep to Build-Depends.
* Added Homepage, Vcs-Svn and Vcs-Browser fields.
* Added watch file.
* Added myself to Uploaders.
* Removed Stafan and Wolfgang from Uploaders.
* Updated Standards-Version to 3.7.3
* Updated debhelper level to 5.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/pgjdbc.xml
1
1
<?xml version="1.0"?>
2
2
<!--
3
3
  Copyright (c) 2004-2005, PostgreSQL Global Development Group
4
 
  $PostgreSQL: pgjdbc/doc/pgjdbc.xml,v 1.25 2005/04/10 15:15:05 jurka Exp $
 
4
  $PostgreSQL: pgjdbc/doc/pgjdbc.xml,v 1.30 2006/09/26 05:18:04 jurka Exp $
5
5
-->
6
6
 
7
7
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
454
454
       <listitem>
455
455
        <para>
456
456
         Act like an older version of the driver to retain compatibility with
457
 
         older applications.  At the moment this controls two driver behaviors,
458
 
         the connection protocol and the handling of binary data fields.
 
457
         older applications.  At the moment this controls two driver behaviors:
 
458
         the handling of binary data fields, and the handling of parameters set
 
459
         via <function>setString()</function>
459
460
        </para>
460
461
        <para>
461
462
         Older versions of the driver used this property to also control the
467
468
         <xref linkend="binary-data" />.  To force the use of
468
469
         Large Objects set the compatible property to 7.1.
469
470
        </para>
 
471
        <para>
 
472
         When <varname>compatible</varname> is set to <literal>7.4</literal> or
 
473
         below, the default for the <varname>stringtype</varname> parameter is
 
474
         changed to <literal>unspecified</literal>.
 
475
        </para>
470
476
       </listitem>
471
477
      </varlistentry>
472
478
 
541
547
      </varlistentry>
542
548
 
543
549
      <varlistentry>
 
550
       <term><varname>logUnclosedConnections</varname> = <type>boolean</type></term>
 
551
       <listitem>
 
552
        <para>
 
553
         Clients may leak <classname>Connection</classname> objects by
 
554
         failing to call its <function>close()</function> method.
 
555
         Eventually these objects will be garbage collected and the
 
556
         <function>finalize()</function> method will be called which will
 
557
         close the <classname>Connection</classname> if caller has
 
558
         neglected to do this himself.  The usage of a finalizer is just
 
559
         a stopgap solution.  To help developers detect and correct the
 
560
         source of these leaks the <literal>logUnclosedConnections</literal>
 
561
         <acronym>URL</acronym> parameter has been added.  It captures
 
562
         a stacktrace at each <classname>Connection</classname> opening
 
563
         and if the <function>finalize()</function> method is reached without
 
564
         having been closed the stacktrace is printed to the log.
 
565
        </para>
 
566
       </listitem>
 
567
      </varlistentry>
 
568
 
 
569
      <varlistentry>
544
570
       <term><varname>prepareThreshold</varname> = <type>int</type></term>
545
571
       <listitem>
546
572
        <para>
547
573
         Determine the number of <classname>PreparedStatement</classname>
548
574
         executions required before switching over to use server side prepared
549
 
         statements.  The default is zero meaning never use server side
550
 
         prepared statements.  More information on server side prepared
 
575
         statements.  The default is five, meaning start using server side
 
576
         prepared statements on the fifth execution of the same
 
577
         <classname>PreparedStatement</classname> object.  More
 
578
         information on server side prepared
551
579
         statements is available in <xref linkend="server-prepare" />.
552
580
        </para>
553
581
       </listitem>
563
591
       </listitem>
564
592
      </varlistentry>
565
593
 
 
594
      <varlistentry>
 
595
       <term><varname>stringtype</varname> = <type>String</type></term>
 
596
       <listitem>
 
597
        <para>
 
598
         Specify the type to use when binding <classname>PreparedStatement</classname> parameters
 
599
         set via <function>setString()</function>. If <varname>stringtype</varname> is set to
 
600
         <literal>varchar</literal> (the default), such parameters will be sent to the server as
 
601
         <type>varchar</type> parameters. If <varname>stringtype</varname> is set to
 
602
         <literal>unspecified</literal>, parameters will be sent to the server as untyped values,
 
603
         and the server will attempt to infer an appropriate type. This is useful if you have an
 
604
         existing application that uses <function>setString()</function> to set parameters that
 
605
         are actually some other type, such as integers, and you are unable to change the
 
606
         application to use an appropriate method such as <function>setInt()</function>.                                    
 
607
        </para>
 
608
       </listitem>
 
609
      </varlistentry>
 
610
 
566
611
     </variablelist>
567
612
    </para>
568
613
 
1057
1102
  <chapter id="callproc">
1058
1103
    <title>Calling Stored Functions</title>
1059
1104
 
1060
 
    <para><productname>PostgreSQL's</productname> <acronym>JDBC</acronym>
1061
 
      driver fully supports calling <productname>PostgreSQL</productname>
1062
 
      stored functions.
1063
 
    
1064
 
      <note>
1065
 
       <para>
1066
 
        The <classname>CallableStatement</classname> support is only as good as
1067
 
        the backend support for stored procedures.
1068
 
        <productname>PostgreSQL</productname> does not support functions that
1069
 
        have output parameters.  This means you may not use
1070
 
        <function>registerOutParameter</function> for anything other than the
1071
 
        function's return value.
1072
 
       </para>
1073
 
      </note>
1074
 
    </para>
1075
 
 
1076
1105
    <example id="call-function-example">
1077
1106
      <title>Calling a built in stored function</title>
1078
1107
 
1997
2026
       <entry>extract(year from arg1)</entry>
1998
2027
       <entry></entry>
1999
2028
      </row>
 
2029
      <row>
 
2030
       <entry>timestampadd(argIntervalType,argCount,argTimeStamp)</entry>
 
2031
       <entry>yes</entry>
 
2032
       <entry>('(interval according to argIntervalType and argCount)'+argTimeStamp)</entry>
 
2033
       <entry>an argIntervalType value of <classname>SQL_TSI_FRAC_SECOND</classname> is not implemented since backend does not support it</entry>
 
2034
      </row>
 
2035
      <row>
 
2036
       <entry>timestampdiff(argIntervalType,argTimeStamp1,argTimeStamp2)</entry>
 
2037
       <entry>not</entry>
 
2038
       <entry>extract((interval according to argIntervalType) from argTimeStamp2-argTimeStamp1  )</entry>
 
2039
       <entry>only an argIntervalType value of <classname>SQL_TSI_FRAC_SECOND</classname>,<classname>SQL_TSI_FRAC_MINUTE</classname>,<classname>SQL_TSI_FRAC_HOUR</classname> or <classname>SQL_TSI_FRAC_DAY</classname> is supported </entry>
 
2040
      </row>
2000
2041
     </tbody>
2001
2042
    </tgroup>
2002
2043
   </table>