From: Ian Barwick <barwick@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Subject: Re: Patch for DBD::Pg pg_relcheck problem
Date: Mon, 16 Dec 2002 00:36:26 +0100
Cc: dbi-dev@perl.org, pgsql-interfaces@postgresql.org,
	david@wheeler.net
References: <200212150109.gBF19JU10544@candle.pha.pa.us>
In-Reply-To: <200212150109.gBF19JU10544@candle.pha.pa.us>
MIME-Version: 1.0
Content-Type: Multipart/Mixed;
	boundary="------------Boundary-00=_QKP6VNAU83PB1USYYDOX"
Message-Id: <200212160036.26713.barwick@gmx.net>

--------------Boundary-00=_QKP6VNAU83PB1USYYDOX
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Sunday 15 December 2002 02:09, Bruce Momjian wrote:
>
> Until we release it, the patch can just sit in CVS.  Just send over a
> new version and I will back out the old one and put in the new one.  I
> will not do any release until you are ready.

Having looked it again I think it can stay as it is.
(It is not very elegant but will fix things until something
better comes along).

Attached is a supplemental patch with an addition for=20
the POD documentation in Pg.pm regarding the status
of schema support in DBD::Pg.=20


Ian Barwick
barwick@gmx.net
--------------Boundary-00=_QKP6VNAU83PB1USYYDOX
Content-Type: text/x-diff;
  charset="iso-8859-1";
  name="Pg.pm.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="Pg.pm.patch"

Index: dbdpg/Pg.pm
===================================================================
RCS file: /usr/local/cvsroot/dbdpg/dbdpg/Pg.pm,v
retrieving revision 1.16
diff -c -r1.16 Pg.pm
*** dbdpg/Pg.pm	14 Dec 2002 23:35:47 -0000	1.16
--- dbdpg/Pg.pm	15 Dec 2002 23:28:50 -0000
***************
*** 1506,1512 ****
  =head2 Large Objects
  
  The driver supports all large-objects related functions provided by libpq via
! the func-interface. Please note, that starting with PoostgreSQL-65. any access
  to a large object - even read-only - has to be put into a transaction!
  
  =head2 Cursors
--- 1506,1512 ----
  =head2 Large Objects
  
  The driver supports all large-objects related functions provided by libpq via
! the func-interface. Please note, that starting with PostgreSQL 6.5 any access
  to a large object - even read-only - has to be put into a transaction!
  
  =head2 Cursors
***************
*** 1522,1537 ****
  =head2 Data-Type bool
  
  The current implementation of PostgreSQL returns 't' for true and 'f' for
! false. From the perl point of view a rather unfortunate choice. The DBD-Pg
  module translates the result for the data-type bool in a perl-ish like manner:
  'f' -> '0' and 't' -> '1'. This way the application does not have to check the
! database-specific returned values for the data-type bool, because perl treats
  '0' as false and '1' as true.
  
! PostgreSQL Version 6.2 considers the input 't' as true and anything else as
! false. PostgreSQL Version 6.3 considers the input 't', '1' and 1 as true and
! anything else as false. PostgreSQL Version 6.4 considers the input 't', '1'
! and 'y' as true and any other character as false.
  
  =head1 SEE ALSO
  
--- 1522,1559 ----
  =head2 Data-Type bool
  
  The current implementation of PostgreSQL returns 't' for true and 'f' for
! false. From the Perl point of view a rather unfortunate choice. The DBD::Pg
  module translates the result for the data-type bool in a perl-ish like manner:
  'f' -> '0' and 't' -> '1'. This way the application does not have to check the
! database-specific returned values for the data-type bool, because Perl treats
  '0' as false and '1' as true.
  
! Boolean values can be passed to PostgreSQL as TRUE, 't', 'true', 'y', 'yes' or
! '1' for true and FALSE, 'f', 'false', 'n', 'no' or '0' for false.
! 
! =head2 Schema support
! 
! PostgreSQL version 7.3 introduced schema support. Note that the PostgreSQL
! schema concept may differ to that of other databases. Please refer to the
! PostgreSQL documentation for more details.
! 
! Currently DBD::Pg does not provide explicit support for PostgreSQL schemas.
! However, schema functionality may be used without any restrictions by
! explicitly addressing schema objects, e.g.
! 
!   my $res = $dbh->selectall_arrayref("SELECT * FROM my_schema.my_table");
! 
! or by manipulating the schema search path with SET search_path, e.g.
! 
!   $dbh->do("SET search_path TO my_schema, public");
! 
! B<NOTE:> If you create an object with the same name as a PostgreSQL system
! object (as contained in the pg_catalog schema) and explicitly set the search
! path so that pg_catalog comes after the new object's schema, some DBD::Pg
! methods (particularly those querying PostgreSQL system objects) may fail.
! This problem should be fixed in a future release of DBD::Pg. Creating objects
! with the same name as system objects (or beginning with 'pg_') is not
! recommended practice and should be avoided in any case.
  
  =head1 SEE ALSO
  

--------------Boundary-00=_QKP6VNAU83PB1USYYDOX--