gmane.comp.db.postgresql.dbdpg

DBD::Pg version 2.19.1 released

Greg Sabino Mullane — 2012-03-11T23:00:37

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Version 2.19.1 of DBD::Pg, the Perl interface to PostgreSQL, 
has just been released. This (and 2.19.0) fixes some serious 
bugs, so upgrading is recommended for all users. You can 
find it at your local CPAN mirror, or at:

http://search.cpan.org/~turnstep/DBD-Pg-2.19.1/

Checksums, MD5 and SHA1:

3a86ac826f5285003b87c6a8b225e0c4  DBD-Pg-2.19.1.tar.gz
0d0bd7daf2c24758716fbbde686e4d66cf81a206  DBD-Pg-2.19.1.tar.gz

Complete list of changes for 2.19.0 and 2.19.1:

  - Fix crash when passing in an array with undefined elements. [GSM]

  - Use proper formatting for warn() and croak() (CPAN bug #75642)
    [Niko Tyni]

  - Fix localized regex in test (CPAN bug #70759)

  - Fix for named placeholders (CPAN bug #70953) [Jan Pazdziora]

  - Various fixes to the array-marshalling code [Noah Misch, Mark 
    Stosberg, and David Christensen] (CPAN bug #58552)

  - Allow hi-bit chars in dollar-quoted identifiers 
    [David Christensen] (CPAN bug #73832)

  - Have do() return count for things such as CREATE TABLE .. AS SELECT
    Will only work on 9.0 or better. (CPAN bug #71073) [Pavel Stehule]

  - Better error message when trying to do things post-disconnect [GSM]

  - Always respect pg_server_prepare=0 by using PQexec not PQexecParams. [GSM]

  - Fix error in async docs (CPAN bug #72812)

  - Switch from subversion to git.
    git clone git://bucardo.org/dbdpg.git [GSM]


- -- 
Greg Sabino Mullane greg-738XdyZ4GzZWk0Htik3J/w< at >public.gmane.org
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201203111859
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAk9dLl4ACgkQvJuQZxSWSsiqtACfUBGbghDPyorMezq6iNADtI+L
Z68AoOnW3LshJjLCb5N8xlFU8k6NNpVO
=0LA5
-----END PGP SIGNATURE-----

feature request

Манол Ружинов — 2012-02-03T16:52:23

Hi,
I need to get the type for a column from query result, but for
Postgres user defined types (composite types) I cannot find DBD::Pg
field  that contains such a  info.
For example for the query:
select A as class_record from pg_class A;

in the resulting DBI statement I have:
$$sth{TYPE}[0]: 0
$$sth{pg_type}[0]: 'unknown'

when the pqlib call PQftype() returns actual OID of the pg_class type.

Currently all calls to  PQftype() are wrapped around pg_type_data()
(for example  pg_type_data((int)PQftype(imp_sth->result, fields)), and
 pg_type_data() always returns NULL if the type is not standard.

I think if the result of PQftype() can be stored in a new pg specific
field (for example pg_type_oid) this will give a way of using composit
types without changing current behavior of the driver ?

Best regards!
Manol

Inconsistent behaviour with Dollar-quoted String Constants

2012-01-07T14:49:05

Hello,

I am using UTF-8 characters within Dollar-quoted tags.
Following code is the problem-setting.

--- CODE BEGIN ---
#!/usr/bin/perl
use strict; use DBI;
my $db = DBI->connect(
     "dbi:Pg:dbname=$PgDbName;host=$PgHost;port=$PgPort",
     $PgSqlUser, $PgSqlPass);

my $txt = '2';
my $delim = "\$\x{5317}\$";

my $sql = "SELECT $delim$txt$delim";
print "SQL = '$sql'\n";
$db->do($sql);
print "after do\n";
$db->selectrow_hashref($sql);
print "after_selectrow_hashref\n";
--- CODE END ---

The script dies during selectrow_hashref and the output of the script is

--- OUTPUT BEGIN ---
SQL = 'SELECT $北$2$北$'
after do
Invalid placeholders: must start at $1 and increment one at a time 
(expected: $1)
--- OUTPUT END ---

It seems like $2 is interpreted as placeholder before the evaluation of 
Dollar-quoting, but only in $db->selectrow_hashref().
The inconsistent part is that $db->do() works just fine.

Regards,
Markus

System: Debian sid with libdbd-pg-perl 2.18.1-1+b1 and perl 5.14.2-6

Inconsistent behaviour with Dollar-quoted String Constants

2012-01-07T14:49:05

Hello,

I am using UTF-8 characters within Dollar-quoted tags.
Following code is the problem-setting.

--- CODE BEGIN ---
#!/usr/bin/perl
use strict; use DBI;
my $db = DBI->connect(
     "dbi:Pg:dbname=$PgDbName;host=$PgHost;port=$PgPort",
     $PgSqlUser, $PgSqlPass);

my $txt = '2';
my $delim = "\$\x{5317}\$";

my $sql = "SELECT $delim$txt$delim";
print "SQL = '$sql'\n";
$db->do($sql);
print "after do\n";
$db->selectrow_hashref($sql);
print "after_selectrow_hashref\n";
--- CODE END ---

The script dies during selectrow_hashref and the output of the script is

--- OUTPUT BEGIN ---
SQL = 'SELECT $北$2$北$'
after do
Invalid placeholders: must start at $1 and increment one at a time 
(expected: $1)
--- OUTPUT END ---

It seems like $2 is interpreted as placeholder before the evaluation of 
Dollar-quoting, but only in $db->selectrow_hashref().
The inconsistent part is that $db->do() works just fine.

Regards,
Markus

System: Debian sid with libdbd-pg-perl 2.18.1-1+b1 and perl 5.14.2-6

Inconsistent behaviour with Dollar-quoted String Constants

2012-01-07T14:49:05

Hello,

I am using UTF-8 characters within Dollar-quoted tags.
Following code is the problem-setting.

--- CODE BEGIN ---
#!/usr/bin/perl
use strict; use DBI;
my $db = DBI->connect(
     "dbi:Pg:dbname=$PgDbName;host=$PgHost;port=$PgPort",
     $PgSqlUser, $PgSqlPass);

my $txt = '2';
my $delim = "\$\x{5317}\$";

my $sql = "SELECT $delim$txt$delim";
print "SQL = '$sql'\n";
$db->do($sql);
print "after do\n";
$db->selectrow_hashref($sql);
print "after_selectrow_hashref\n";
--- CODE END ---

The script dies during selectrow_hashref and the output of the script is

--- OUTPUT BEGIN ---
SQL = 'SELECT $北$2$北$'
after do
Invalid placeholders: must start at $1 and increment one at a time 
(expected: $1)
--- OUTPUT END ---

It seems like $2 is interpreted as placeholder before the evaluation of 
Dollar-quoting, but only in $db->selectrow_hashref().
The inconsistent part is that $db->do() works just fine.

Regards,
Markus

System: Debian sid with libdbd-pg-perl 2.18.1-1+b1 and perl 5.14.2-6

DBD::Pg::hstore

David E. Wheeler — 2011-11-22T03:06:38

Hi Galimov,

Thanks for DBD::Pg::hstore, it looks interesting. However, I think the name isn’t great. There is nothing DBD::Pg specific about it, is there? You just have the decode() and encode() functions that take strings, yes?

If so, I think a better name might be Pg::Hstore (or Pg::hstore if you prefer). I also suggest giveing the exported functions longer names, like encode_hstore() and decode_hstore(), to prevent conflicts with, e.g., the Encode module.

Looking forward to giving your module a try. Thank you!

Best,

David

DBI::Pg

John Arnold — 2011-11-10T17:33:17

Gentlemen

I am having a little connectivity issue, that I think might be PostgreSQL related and not DBI::Pg per se (but I have to start somewhere :) )

The error: seems to indicate a local issue rather than a remote issue. Why is the script looking for a local pg_hba.conf file?

DBI connect('dbname=taskman;host=xx.xxx.xx.xx;port=5432','postgres',...) failed: FATAL: could not load pg_hba.conf at C:/Documents and Settings/xxxxxxx/workspace/Forms/pg_connect.pl

seems to indicate a local issue rather than a remote issue. Why is the script looking for a local pg_hba.conf file, since this conf file controls client connections on the SERVER side?

Thoughts?

----------------------------------------- This electronic mail
message, and any of the accompanying documents, may contain
confidential or privileged information. Any unauthorized disclosure
or distribution of such information is strictly prohibited. If you
are not the intended recipient of this message, please notify the
sender immediately and destroy the message. Messages sent through
electronic media may be subject to delays or unauthorized
alterations. Neither The Bank of Tokyo-Mitsubishi UFJ, Ltd. nor any
of its affiliates is responsible for any such delay or alteration.
This message may contain a commercial advertisement or promotion of
a commercial product or service. If you do not wish to receive
messages of this kind from the sender in the future, please reply
to this message and type "REMOVE MY EMAIL ADDRESS" in the subject
field, or write to the sender at 1251 Avenue of the Americas, New
York, NY 10020-1104.

A couple complex type and array questions

Chris Travers — 2011-11-08T00:20:01

Hi all;

1) I remember reading previously about complex type support in
DBD::Pg, but reading through the perl module code, I can't find how
hashrefs are mapped to string representations of tuples.  Is this in
fact supported at present?  Is there a private method  I can call for
the parsing (for reasons, see below)?

2) Reading through the DBD::Pg code, I am guessing it is not possible
to pass arrays of complex types to DBD::Pg is it?

3) If I want to use table definitions as complex types, this won't
work with the current discovery, correct?

Would the DBD::Pg team be interested in patches at some point on these
areas?  My plan is to copy relevant portions of DBD::Pg into my app
(in my app's namespaces) and tweak them, and then once they are
working I could use them from there pending generally available
versions with the same functionality.

Best Wishes,
Chris Travers

Quoting of values in arrays in broken in DBD::Pg, can you help fix it? ( CPAN RT#58552 ) [SumsaultRT #9386]

Mark Stosberg — 2011-10-07T19:44:38

Hello,

If you use DBD::Pg and also use PostgreSQL arrays, you should be aware
there is an open bug with quoting PostgreSQL array values. A bug report
about the issue is here, including some related test cases and work on
some patches:

https://rt.cpan.org/Public/Bug/Display.html?id=58552

However, the proposed fix is not passing all the test cases. The
solution will need someone with XS skills, who also has confidence about
exactly what the correct quoting behavior should be.

I'm affected by the issue and would personally appreciate the help.

Thanks!

    Mark

Transaction wrapper

Florian Weimer — 2011-08-24T07:29:15

Is there are ready-to-use transaction wrapper for DBD:Pg?  I'm looking
for somehting which can be used like this:

    my $connect_args = [$data_source, $username, $auth, \%attr];
    transact $connect_args, sub {
      my ($dbh) = < at >_;
      $dbh->begin_work;
      ...
      $dbh->commit;
    };

The transact subroutine should abort the transaction if the passed sub
dies.  For certain exceptions, the sub should be called again to retry
the transaction.  The database handle should be cached.

This is somewhat PostgreSQL-specific because there are three cases:
permanent errors (such as SQL syntax errors, or non-SQL exceptions),
transient errors which will go away when the transaction is retried
within the same connection (such as serialization failures and certain
types of UNIQUE constraint violations), and errors which will likely go
away when the transaction is retried with a fresh connection (due to
server restart, for example).

This is not very difficult to write as such, but getting the error code
list right is a bit delicate.

Installing DBD::Pg on Windows Vista

David Rogers — 2011-07-13T20:50:44

I am attempting to install DBD::Pg on a Windows Vista Ultimate machine for
my own personal use.  I am retired now, but did work with database systems
and expert systems.  I am developing a database for some linguistic
research.  Because others are using Perl (but not with a database) I really
need to include Perl routines in my work.  I have version 8.4 of PostgreSQL
and version 1.10.5 of PostgreSQL Tools.  They appear to be working, except
for the Perl interface.


I have downloaded DBD-Pg-2.18.1.tar.gz and have unzipped it, the result now
in C:\tmp\ DBD-Pg-2.18.1.  In step 1 of your instructions in “How to get
working DBD::Pg on Windows” you state to use MS Visual C++.  I do not have
this package, but do have C and Java.  Could I use C, and, if so, how would
that change your instructions?



Thanks for any help.

segfault in dbdimp.c:319

Avriette, Alex [USA] — 2011-07-10T12:00:59

Hi Greg. My code was tickling a segfault in dbd::pg (which caused perl to
segfault, or the other way around, or whichever). This may be Tim's code
originally, so I don't know if it's your "hack," but it seems the hack is
no longer working. Here's a backtrace.

(gdb) bt
#0  0x0000000100677720 in pg_warn (arg=<value temporarily unavailable, due
to optimizations>, message=0x1011e9810 "LOG:  statement: DEALLOCATE
dbdpg_p62640_1\n") at dbdimp.c:319
#1  0x00000001006b4f90 in pqGetErrorNotice3 ()
#2  0x00000001006b65ca in pqParseInput3 ()
#3  0x00000001006ae5a4 in PQgetResult ()
#4  0x00000001006ae7c8 in PQexecFinish ()
#5  0x000000010067f59e in _result (my_perl=0x100800000,
imp_dbh=0x1014929c0, sql=0x1002027f0 "DEALLOCATE dbdpg_p62640_1") at
dbdimp.c:353
#6  0x0000000100682940 in pg_st_deallocate_statement (my_perl=0x100800000,
sth=0x10082fb48, imp_sth=0x101494910) at dbdimp.c:3631
#7  0x0000000100682e74 in pg_st_destroy (sth=0x10082fb48,
imp_sth=0x101494910) at dbdimp.c:3684
#8  0x000000010067041d in XS_DBD__Pg__st_DESTROY (my_perl=0x100800000,
cv=<value temporarily unavailable, due to optimizations>) at Pg.xsi:769
#9  0x00000001001ca61b in XS_DBI_dispatch ()
#10 0x0000000100075708 in Perl_pp_entersub ()
#11 0x0000000100069550 in Perl_call_sv ()
#12 0x000000010007bef1 in Perl_sv_clear ()
#13 0x000000010007c49b in Perl_sv_free2 ()
#14 0x000000010007c389 in Perl_sv_clear ()
#15 0x000000010007c49b in Perl_sv_free2 ()
#16 0x00000001000585c0 in Perl_mg_free ()
#17 0x000000010007c0bf in Perl_sv_clear ()
#18 0x000000010007c49b in Perl_sv_free2 ()
#19 0x0000000100076889 in Perl_sv_add_arena ()
#20 0x00000001000768df in Perl_sv_clean_objs ()
#21 0x0000000100069ec5 in perl_destruct ()
#22 0x0000000100000db0 in ?? ()
#23 0x0000000100000cb8 in ?? ()



The problem is apparently when logging statements is set to 'all' in the
postmaster and when the loglevel is notice or below. The code (starting at
319) says it tries to address it. But it's segfaulting. I'm using 9.0.4 of
the postmaster. Here's my uname -a:

Darwin wing 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT
2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

And my perl -V:


wing:~ alex$ perl -V
Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
  Platform:
    osname=darwin, osvers=10.0, archname=darwin-thread-multi-2level
    uname='darwin scream.apple.com 10.0 darwin kernel version 10.0.0: fri
jul 31 22:46:25 pdt 2009; root:xnu-1456.1.25~1release_x86_64 x86_64 '
    config_args='-ds -e -Dprefix=/usr -Dccflags=-g  -pipe  -Dldflags=
-Dman3ext=3pm -Duseithreads -Duseshrplib -Dinc_version_list=none
-Dcc=gcc-4.2'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc-4.2', ccflags ='-arch x86_64 -arch i386 -arch ppc -g -pipe
-fno-common -DPERL_DARWIN -fno-strict-aliasing -I/usr/local/include',
    optimize='-Os',
    cppflags='-g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing
-I/usr/local/include'
    ccversion='', gccversion='4.2.1 (Apple Inc. build 5646)',
gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='gcc-4.2 -mmacosx-version-min=10.6.4', ldflags ='-arch x86_64 -arch
i386 -arch ppc -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib
    libs=-ldbm -ldl -lm -lutil -lc
    perllibs=-ldl -lm -lutil -lc
    libc=/usr/lib/libc.dylib, so=dylib, useshrplib=true,
libperl=libperl.dylib
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-arch x86_64 -arch i386 -arch ppc -bundle
-undefined dynamic_lookup -L/usr/local/lib'


Characteristics of this binary (from libperl):
  Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
                        PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP
USE_64_BIT_ALL
                        USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES
                        USE_PERLIO USE_REENTRANT_API
  Locally applied patches:
/Library/Perl/Updates/<version> comes before system perl directories
installprivlib and installarchlib points to the Updates directory
  Built under darwin
  Compiled at Jun 24 2010 17:31:03
  < at >INC:
    /Library/Perl/Updates/5.10.0/darwin-thread-multi-2level
    /Library/Perl/Updates/5.10.0
    /System/Library/Perl/5.10.0/darwin-thread-multi-2level
    /System/Library/Perl/5.10.0
    /Library/Perl/5.10.0/darwin-thread-multi-2level
    /Library/Perl/5.10.0
    /Network/Library/Perl/5.10.0/darwin-thread-multi-2level
    /Network/Library/Perl/5.10.0
    /Network/Library/Perl
    /System/Library/Perl/Extras/5.10.0/darwin-thread-multi-2level
    /System/Library/Perl/Extras/5.10.0
    .

And I am using DBD::Pg version


DBD::Pg is up to date (2.18.1).

I turned the logging to "warning" from "notice" and the segfaults stopped.


Thanks for your attention.

DBD::Pg 2.9.2 make error

VANOLE, MICHAEL J (ATTSI — 2011-06-24T21:13:26

Hi,

I can't get past make. 

Perl 5.014000 on sun4-solaris-thread-multi
gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
DBI 1.616
Solaris 5.10
DBD Pg 2.9.2
(PostgreSQL) 9.1beta2

I'm getting the output below which isn't telling me much. Any help or ideas about this one would be great.
Thank you in advance
Mike

ecdwtool< at >bstst17 $ perl Makefile.PL
Configuring DBD::Pg 2.9.2
PostgreSQL version: 90100 (default port: 5432)
POSTGRES_HOME: /opt/app/t1cdw1c2/ecdwtools/local/pgsql/lib
POSTGRES_INCLUDE: /opt/app/t1cdw1c2/ecdwtools/local/pgsql/include
POSTGRES_LIB: /opt/app/t1cdw1c2/ecdwtools/local/pgsql/lib
OS: solaris
Checking if your kit is complete...
Looks good
Using DBI 1.616 (for perl 5.014000 on sun4-solaris-thread-multi) installed in /opt/app/t1cdw1c2/ecdwtools/local/lib/perl5/site_perl/5.14.0/sun4-solaris-thread-multi/auto/DBI/
Writing Makefile for DBD::Pg
Writing MYMETA.yml

ecdwtool< at >bstst17 $ make
cp lib/Bundle/DBD/Pg.pm blib/lib/Bundle/DBD/Pg.pm
cp Pg.pm blib/lib/DBD/Pg.pm
/opt/app/t1cdw1c2/ecdwtools/local/bin/perl -p -e "s/~DRIVER~/Pg/g; s/^do\(/dontdo\(/" /opt/app/t1cdw1c2/ecdwtools/local/lib/perl5/site_perl/5.14.0/sun4-solaris-thread-multi/auto/DBI/Driver.xst > Pg.xsi
/opt/app/t1cdw1c2/ecdwtools/local/bin/perl /opt/app/t1cdw1c2/ecdwtools/local/lib/perl5/5.14.0/ExtUtils/xsubpp  -typemap /opt/app/t1cdw1c2/ecdwtools/local/lib/perl5/5.14.0/ExtUtils/typemap  Pg.xs > Pg.xsc && mv Pg.xsc Pg.c
gcc -c  -I/opt/app/t1cdw1c2/ecdwtools/local/pgsql/include -I/opt/app/t1cdw1c2/ecdwtools/local/lib/perl5/site_perl/5.14.0/sun4-solaris-thread-multi/auto/DBI -D_REENTRANT -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV -DPERL_USE_SAFE_PUTENV -DPGLIBVERSION=90100 -DPGDEFPORT=5432 -O  -DPERL_EXTMALLOC_DEF -Dmalloc=Perl_malloc -Dfree=Perl_mfree -Drealloc=Perl_realloc -Dcalloc=Perl_calloc -DVERSION=\"2.9.2\" -DXS_VERSION=\"2.9.2\" -fPIC "-I/opt/app/t1cdw1c2/ecdwtools/local/lib/perl5/5.14.0/sun4-solaris-thread-multi/CORE"   Pg.c
Pg.xs: In function `XS_DBD__Pg__db_state':
Pg.xs:272: error: `sv_no' undeclared (first use in this function)
Pg.xs:272: error: (Each undeclared identifier is reported only once
Pg.xs:272: error: for each function it appears in.)
Pg.xs: In function `XS_DBD__Pg__db_pg_endcopy':
Pg.xs:344: error: `sv_no' undeclared (first use in this function)
Pg.xs:344: error: `sv_yes' undeclared (first use in this function)
Pg.xs: In function `XS_DBD__Pg__db_pg_savepoint':
Pg.xs:363: error: `sv_yes' undeclared (first use in this function)
Pg.xs:363: error: `sv_no' undeclared (first use in this function)
Pg.xs: In function `XS_DBD__Pg__db_pg_rollback_to':
Pg.xs:374: error: `sv_yes' undeclared (first use in this function)
Pg.xs:374: error: `sv_no' undeclared (first use in this function)
Pg.xs: In function `XS_DBD__Pg__db_pg_release':
Pg.xs:385: error: `sv_yes' undeclared (first use in this function)
Pg.xs:385: error: `sv_no' undeclared (first use in this function)
Pg.xs: In function `XS_DBD__Pg__db_lo_creat':
Pg.xs:394: error: `sv_undef' undeclared (first use in this function)
Pg.xs: In function `XS_DBD__Pg__db_lo_open':
Pg.xs:404: error: `sv_undef' undeclared (first use in this function)
Pg.xs: In function `XS_DBD__Pg__db_lo_close':
Pg.xs:412: error: `sv_yes' undeclared (first use in this function)
Pg.xs:412: error: `sv_no' undeclared (first use in this function)
Pg.xs: In function `XS_DBD__Pg__db_lo_read':
Pg.xs:434: error: `sv_undef' undeclared (first use in this function)
Pg.xs: In function `XS_DBD__Pg__db_lo_write':
Pg.xs:445: error: `sv_undef' undeclared (first use in this function)
Pg.xs: In function `XS_DBD__Pg__db_lo_lseek':
Pg.xs:456: error: `sv_undef' undeclared (first use in this function)
Pg.xs: In function `XS_DBD__Pg__db_lo_tell':
Pg.xs:465: error: `sv_undef' undeclared (first use in this function)
Pg.xs: In function `XS_DBD__Pg__db_lo_unlink':
Pg.xs:473: error: `sv_yes' undeclared (first use in this function)
Pg.xs:473: error: `sv_no' undeclared (first use in this function)
Pg.xs: In function `XS_DBD__Pg__db_lo_import':
Pg.xs:482: error: `sv_undef' undeclared (first use in this function)
Pg.xs: In function `XS_DBD__Pg__db_lo_export':
Pg.xs:491: error: `sv_yes' undeclared (first use in this function)
Pg.xs:491: error: `sv_no' undeclared (first use in this function)
Pg.xs: In function `XS_DBD__Pg__db_pg_putline':
Pg.xs:499: error: `sv_no' undeclared (first use in this function)
Pg.xs:499: error: `sv_yes' undeclared (first use in this function)
Pg.xs: In function `XS_DBD__Pg__db_putline':
Pg.xs:507: error: `sv_no' undeclared (first use in this function)
Pg.xs:507: error: `sv_yes' undeclared (first use in this function)
Pg.xs: In function `XS_DBD__Pg__db_pg_getline':
Pg.xs:528: error: `sv_yes' undeclared (first use in this function)
Pg.xs:528: error: `sv_no' undeclared (first use in this function)
Pg.xs: In function `XS_DBD__Pg__db_getline':
Pg.xs:584: error: `sv_yes' undeclared (first use in this function)
Pg.xs:584: error: `sv_no' undeclared (first use in this function)
Pg.xs: In function `XS_DBD__Pg__db_endcopy':
Pg.xs:590: error: `sv_yes' undeclared (first use in this function)
Pg.xs:590: error: `sv_no' undeclared (first use in this function)
Pg.xs: In function `XS_DBD__Pg__db_pg_cancel':
Pg.xs:650: error: `sv_yes' undeclared (first use in this function)
Pg.xs:650: error: `sv_no' undeclared (first use in this function)
Pg.xs: In function `XS_DBD__Pg__st_state':
Pg.xs:667: error: `sv_no' undeclared (first use in this function)
Pg.xs: In function `XS_DBD__Pg__st_pg_cancel':
Pg.xs:682: error: `sv_yes' undeclared (first use in this function)
Pg.xs:682: error: `sv_no' undeclared (first use in this function)
make: *** [Pg.o] Error 1

The DBD::Pg repo is now in git

Greg Sabino Mullane — 2011-06-05T20:36:06

The day is finally here - as of now, the official DBD::Pg repo is
in git. You can pull it at:

git clone git://bucardo.org/dbdpg.git

or if you prefer, there is a github mirror:

https://github.com/bucardo/dbdpg

If you need/want commit access, please let me know. Everything else
should be the same, especially for non-committers.

Help regarding ActiveState's PPM repository module for DBD-pg -- which is currently unavailable!

Lawrence Hixson — 2011-04-15T19:48:58

Hello!

I sit on The Perl Foundation's Steering Committee as the Donor Relations 
Chair and I may have meet some of you at previous YAPC's.

First, I want to personally THANK YOU ALL for supporting Perl and the 
Perl Community with your programming skills!  Secondly, I thank you for 
supporting PostgreSQL, which I'm anxious to use with my version of Perl!

I've just recently started trying to work with PostgreSQL and want the 
full capabilities (or the most I can get) of the database using Perl, 
but I'm forced to use ActiveState by my employer for various security 
and IT policy reasons.

I'm running ActivePerl 5.12.2 and cannot find your driver using their 
PPM module installer.

More research yields this:   http://code.activestate.com/ppm/DBD-Pg/    
and clicking on red ! buttons shows why.  I notice that this driver is 
not available for ANY recent ActiveState version and I think it should be.

I found this same situation was true for DBD-mysql, but I intervened and 
connected the module author and ActiveState and at least now the 
ActiveState DBD-mysql driver has some working versions that can be 
installed and work fine!
Please see  http://code.activestate.com/ppm/DBD-mysql/

Not just for myself, but for the greater ActiveState Perl community, may 
I please ask for your assistance in working with ActiveState to school 
them on how to get your module to compile for their module repositories 
so more of us can use PostgreSQL more fully?

These are two GREAT people at ActiveState who can either help you or 
direct you to those who can help to get your module working with 
ActivePerl !

Jan Dubois at   jand-0OmgUqZ5G+O9C01uVemLPA< at >public.gmane.org

Jeff Hobbs  at   jeffh-0OmgUqZ5G+O9C01uVemLPA< at >public.gmane.org

If I can be of any other assistance to you, please email me!  I plan to 
attend YAPC::NA 2011 in Asheville, North Carolina, USA.  I hope some of 
you will be attending!

Sincerely,
Lawrence K. Hixson
Principal Systems Engineer/DBA
U.S. National Weather Service
Silver Spring, Maryland, USA
301-713-0022 x190

autocommit bug?

John Payne — 2011-04-02T00:02:12

Hi,

 

I'm using DBD::Pg to access a PostgreSQL database with a Perl script, and
having trouble with AutoCommit: the standard syntax fails to set it.  I have
tried both setting it during the connection: 

 

       my $dbh = DBI->connect ( 'DBI:Pg:dbname=' . $dbname, $dbuser,
$passwd,{AutoCommit => 0, RaiseError => 1});

 

.and setting it after the connection is made:

 

        $dbh->{Autocommit} = 0;

 

Neither seems to work, because I get an error message when I try the
$dbh->begin_work() command, and when I check the value of the flag by
typing:

 

            print $dbh->{AutoCommit}, it returns 1, even immediately after
setting it.  I've tried disconnecting and reconnecting, without luck.

 

Can you suggest anything?

 

Thanks,

 

John

Consistently report CONNECTION_BAD state to applications.

Rainer Weikusat — 2011-03-22T22:31:09

NB: This posting is a copy of

https://rt.cpan.org/Public/Bug/Display.html?id=66792

intended to enable 'easier' discussion of the proposed change.

Whenever a libpq function whose status cannot be queried by examining a
PGresult fails, the driver just reports a 'fatal error' to an
application using it without providing more specific information via
imp_dbh->sqlstate. This is unfortunate for long running applications
manageing persistent database connection because these cannot
distinguish between 'unexpected errors' (possibly caused by programming
errors in the application) and TCP connection failures which can 'just
happen' on the internet, where an automated remedy (try to re-establish
the connection perdiodically until success) is easily available. The
driver itself can detect this by examining the connection status via
PQconnStatus call.

Attached is a patch which (IMHO) improves this situation by introducing
a _fatal_sqlstate function setting the sqlstate of the dbh either to
08000 (connection exception) or 22000 (data exception), based on the
result of PQconnStatus. Calls to this function have been inserted in
front of all pg_error invocations happening because of some kind of
libpq error return. It also changes the error handling in pg_db_cancel
to set the sqlstate via _sqlstate before calling pg_error. I've also
taken the liberty to streamline the _sqlstate function somewhat, by
dropping the technically redundant stateset variable and consolidiating
the various strncpy operations into one copying the value of the
sqlstate variable pointing to the 'best sqlstate' the function could
determine.

---
--- DBD-Pg-eh-fix-2/dbdimp.c18 Mar 2011 22:20:38 -00001.1.1.5
+++ DBD-Pg-eh-fix-2/dbdimp.c21 Mar 2011 22:46:41 -00001.1.1.5.2.4
< at >< at > -81,6 +81,7 < at >< at > typedef enum
 static void pg_error(pTHX_ SV *h, int error_num, const char *error_msg);
 static void pg_warn (void * arg, const char * message);
 static ExecStatusType _result(pTHX_ imp_dbh_t *imp_dbh, const char *sql);
+static void _fatal_sqlstate(pTHX_ imp_dbh_t *imp_dbh);
 static ExecStatusType _sqlstate(pTHX_ imp_dbh_t *imp_dbh, PGresult *result);
 static int pg_db_rollback_commit (pTHX_ SV *dbh, imp_dbh_t *imp_dbh, int action);
 static void pg_st_split_statement (pTHX_ imp_sth_t *imp_sth, int version, char *statement);
< at >< at > -356,13 +357,24 < at >< at > static ExecStatusType _result(pTHX_ imp_
 
 } /* end of _result */
 
+/* ================================================================== */
+/* Set the SQLSTATE for a 'fatal' error */
+static void _fatal_sqlstate(pTHX_ imp_dbh_t * imp_dbh)
+{
+char *sqlstate;
+
+sqlstate = PQstatus(imp_dbh->conn) == CONNECTION_BAD ?
+"08000" :/* CONNECTION EXCEPTION */
+"22000";/* DATA EXCEPTION */
+strncpy(imp_dbh->sqlstate, sqlstate, 6);
+}
 
 /* ================================================================== */
 /* Set the SQLSTATE based on a result, returns the status */
 static ExecStatusType _sqlstate(pTHX_ imp_dbh_t * imp_dbh, PGresult * result)
 {
+char *sqlstate;
 ExecStatusType status   = PGRES_FATAL_ERROR; /* until proven otherwise */
-bool           stateset = DBDPG_FALSE;
 
 if (TSTART) TRC(DBILOGFP, "%sBegin _sqlstate\n", THEADER);
 
< at >< at > -371,6 +383,8 < at >< at > static ExecStatusType _sqlstate(pTHX_ im
 status = PQresultStatus(result);
 }
 
+sqlstate = NULL;
+
 /*
   Because PQresultErrorField may not work completely when an error occurs, and 
   we are connecting over TCP/IP, only set it here if non-null, and fall through 
< at >< at > -378,14 +392,10 < at >< at > static ExecStatusType _sqlstate(pTHX_ im
 */
 if (result) {
 TRACE_PQRESULTERRORFIELD;
-if (NULL != PQresultErrorField(result,PG_DIAG_SQLSTATE)) {
-TRACE_PQRESULTERRORFIELD;
-strncpy(imp_dbh->sqlstate, PQresultErrorField(result,PG_DIAG_SQLSTATE), 5);
-imp_dbh->sqlstate[5] = '\0';
-stateset = DBDPG_TRUE;
-}
+sqlstate = PQresultErrorField(result, PG_DIAG_SQLSTATE);
 }
-if (!stateset) {
+
+if (!sqlstate) {
 /* Do our best to map the status result to a sqlstate code */
 switch (status) {
 case PGRES_EMPTY_QUERY:
< at >< at > -393,24 +403,28 < at >< at > static ExecStatusType _sqlstate(pTHX_ im
 case PGRES_TUPLES_OK:
 case PGRES_COPY_OUT:
 case PGRES_COPY_IN:
-strncpy(imp_dbh->sqlstate, "00000", 6); /* SUCCESSFUL COMPLETION */
+sqlstate = "00000";/* SUCCESSFUL COMPLETION */
 break;
 case PGRES_BAD_RESPONSE:
 case PGRES_NONFATAL_ERROR:
-strncpy(imp_dbh->sqlstate, "01000", 6); /* WARNING */
+sqlstate = "01000";/* WARNING */
 break;
 case PGRES_FATAL_ERROR:
-if (!result) { /* libpq returned null - some sort of connection problem */
-strncpy(imp_dbh->sqlstate, "08000", 6); /* CONNECTION EXCEPTION */
+/* libpq returns NULL result in case of connection failures */
+if (!result || PQstatus(imp_dbh->conn) == CONNECTION_BAD) {
+sqlstate = "08000";/* CONNECTION EXCEPTION */
 break;
 }
 /*< at >fallthrough< at >*/
 default:
-strncpy(imp_dbh->sqlstate, "22000", 6); /* DATA EXCEPTION */
+sqlstate = "22000";/* DATA EXCEPTION */
 break;
 }
 }
 
+strncpy(imp_dbh->sqlstate, sqlstate, 5);
+imp_dbh->sqlstate[5] = 0;
+
 if (TEND) TRC(DBILOGFP, "%sEnd _sqlstate (imp_dbh->sqlstate: %s)\n",
   THEADER, imp_dbh->sqlstate);
 
< at >< at > -1356,7 +1370,9 < at >< at > SV * pg_db_pg_notifies (SV * dbh, imp_db
 
 TRACE_PQCONSUMEINPUT;
 status = PQconsumeInput(imp_dbh->conn);
-if (0 == status) { 
+if (0 == status) {
+_fatal_sqlstate(aTHX_ imp_dbh);
+
 TRACE_PQERRORMESSAGE;
 pg_error(aTHX_ dbh, PGRES_FATAL_ERROR, PQerrorMessage(imp_dbh->conn));
 if (TEND) TRC(DBILOGFP, "%sEnd pg_db_pg_notifies (error)\n", THEADER);
< at >< at > -2745,6 +2761,8 < at >< at > int pg_quickexec (SV * dbh, const char *
 TRACE_PQSENDQUERY;
 if (! PQsendQuery(imp_dbh->conn, sql)) {
 if (TRACE4) TRC(DBILOGFP, "%sPQsendQuery failed\n", THEADER);
+_fatal_sqlstate(aTHX_ imp_dbh);
+
 TRACE_PQERRORMESSAGE;
 pg_error(aTHX_ dbh, status, PQerrorMessage(imp_dbh->conn));
 if (TEND) TRC(DBILOGFP, "%sEnd pg_quickexec (error: async do failed)\n", THEADER);
< at >< at > -3725,6 +3743,8 < at >< at > pg_db_putline (SV * dbh, const char * bu
 TRACE_PQPUTCOPYDATA;
 copystatus = PQputCopyData(imp_dbh->conn, buffer, (int)strlen(buffer));
 if (-1 == copystatus) {
+_fatal_sqlstate(aTHX_ imp_dbh);
+
 TRACE_PQERRORMESSAGE;
 pg_error(aTHX_ dbh, PGRES_FATAL_ERROR, PQerrorMessage(imp_dbh->conn));
 if (TEND) TRC(DBILOGFP, "%sEnd pg_db_putline (error: copystatus not -1)\n", THEADER);
< at >< at > -3773,6 +3793,8 < at >< at > pg_db_getline (SV * dbh, SV * svbuf, int
 return -1;
 }
 else if (copystatus < 1) {
+_fatal_sqlstate(aTHX_ imp_dbh);
+
 TRACE_PQERRORMESSAGE;
 pg_error(aTHX_ dbh, PGRES_FATAL_ERROR, PQerrorMessage(imp_dbh->conn));
 }
< at >< at > -3815,6 +3837,8 < at >< at > pg_db_getcopydata (SV * dbh, SV * datali
 else if (0 == copystatus) { /* async and still in progress: consume and return */
 TRACE_PQCONSUMEINPUT;
 if (!PQconsumeInput(imp_dbh->conn)) {
+_fatal_sqlstate(aTHX_ imp_dbh);
+
 TRACE_PQERRORMESSAGE;
 pg_error(aTHX_ dbh, PGRES_FATAL_ERROR, PQerrorMessage(imp_dbh->conn));
 if (TEND) TRC(DBILOGFP, "%sEnd pg_db_getcopydata (error: async in progress)\n", THEADER);
< at >< at > -3837,6 +3861,8 < at >< at > pg_db_getcopydata (SV * dbh, SV * datali
 }
 }
 else {
+_fatal_sqlstate(aTHX_ imp_dbh);
+
 TRACE_PQERRORMESSAGE;
 pg_error(aTHX_ dbh, PGRES_FATAL_ERROR, PQerrorMessage(imp_dbh->conn));
 }
< at >< at > -3874,6 +3900,8 < at >< at > pg_db_putcopydata (SV * dbh, SV * datali
 else if (0 == copystatus) { /* non-blocking mode only */
 }
 else {
+_fatal_sqlstate(aTHX_ imp_dbh);
+
 TRACE_PQERRORMESSAGE;
 pg_error(aTHX_ dbh, PGRES_FATAL_ERROR, PQerrorMessage(imp_dbh->conn));
 }
< at >< at > -3937,6 +3965,8 < at >< at > int pg_db_putcopyend (SV * dbh)
 return 0;
 }
 else {
+_fatal_sqlstate(aTHX_ imp_dbh);
+
 TRACE_PQERRORMESSAGE;
 pg_error(aTHX_ dbh, PGRES_FATAL_ERROR, PQerrorMessage(imp_dbh->conn));
 if (TEND) TRC(DBILOGFP, "%sEnd pg_db_putcopyend (error: copystatus unknown)\n", THEADER);
< at >< at > -3964,6 +3994,8 < at >< at > int pg_db_endcopy (SV * dbh)
 TRACE_PQPUTCOPYEND;
 copystatus = PQputCopyEnd(imp_dbh->conn, NULL);
 if (-1 == copystatus) {
+_fatal_sqlstate(aTHX_ imp_dbh);
+
 TRACE_PQERRORMESSAGE;
 pg_error(aTHX_ dbh, PGRES_FATAL_ERROR, PQerrorMessage(imp_dbh->conn));
 if (TEND) TRC(DBILOGFP, "%sEnd pg_db_endcopy (error)\n", THEADER);
< at >< at > -4707,6 +4739,8 < at >< at > int pg_db_ready(SV *h, imp_dbh_t *imp_db
 
 TRACE_PQCONSUMEINPUT;
 if (!PQconsumeInput(imp_dbh->conn)) {
+_fatal_sqlstate(aTHX_ imp_dbh);
+
 TRACE_PQERRORMESSAGE;
 pg_error(aTHX_ h, PGRES_FATAL_ERROR, PQerrorMessage(imp_dbh->conn));
 if (TEND) TRC(DBILOGFP, "%sEnd pg_db_ready (error: consume failed)\n", THEADER);
< at >< at > -4761,6 +4795,9 < at >< at > int pg_db_cancel(SV *h, imp_dbh_t *imp_d
 TRACE_PQFREECANCEL;
 PQfreeCancel(cancel);
 if (TRACEWARN) { TRC(DBILOGFP, "%sPQcancel failed: %s\n", THEADER, errbuf); }
+
+_fatal_sqlstate(aTHX_ imp_dbh);
+
 pg_error(aTHX_ h, PGRES_FATAL_ERROR, "PQcancel failed");
 if (TEND) TRC(DBILOGFP, "%sEnd pg_db_cancel (error: cancel failed)\n", THEADER);
 return DBDPG_FALSE;
< at >< at > -4776,14 +4813,14 < at >< at > int pg_db_cancel(SV *h, imp_dbh_t *imp_d
 /* Read in the result - assume only one */
 TRACE_PQGETRESULT;
 result = PQgetResult(imp_dbh->conn);
+status = _sqlstate(aTHX_ imp_dbh, result);
+
 if (!result) {
 pg_error(aTHX_ h, PGRES_FATAL_ERROR, "Failed to get a result after PQcancel");
 if (TEND) TRC(DBILOGFP, "%sEnd pg_db_cancel (error: no result)\n", THEADER);
 return DBDPG_FALSE;
 }
 
-status = _sqlstate(aTHX_ imp_dbh, result);
-
 TRACE_PQCLEAR;
 PQclear(result);
 
< at >< at > -4855,6 +4892,9 < at >< at > static int handle_old_async(pTHX_ SV * h
 cresult = PQcancel(cancel,errbuf,255);
 if (! cresult) {
 if (TRACEWARN) { TRC(DBILOGFP, "%sPQcancel failed: %s\n", THEADER, errbuf); }
+
+_fatal_sqlstate(aTHX_ imp_dbh);
+
 pg_error(aTHX_ handle, PGRES_FATAL_ERROR, "Could not cancel previous command");
 if (TEND) TRC(DBILOGFP, "%sEnd handle_old_async (error: could not cancel)\n", THEADER);
 return -2;

'RAISE NOTICE' does not set $sth->err

Lamprecht — 2011-03-17T15:09:28

Hello,

I came across the following issue: $sth->err is documented to return 6 in case 
of a PGRES_NONFATAL_ERROR (PG notice or warning).
Here it returns undef instead:

Cheers, Christoph LAmprecht


use strict;
use warnings;

use DBI;
use DBD::Pg;
use Test::More 'no_plan';

my $dh = DBI->connect(
             "DBI:Pg:dbname=testdb",
         ) or die $DBI::errstr;

$dh->do(
q|CREATE OR REPLACE FUNCTION test_error_handler(character varying)
   RETURNS boolean AS
$BODY$
DECLARE
    level ALIAS FOR $1;
BEGIN

IF level ~* 'notice' THEN

   RAISE NOTICE 'RAISE NOTICE FROM test_error_handler';

ELSIF level ~* 'warning' THEN

   RAISE WARNING 'RAISE WARNING FROM test_error_handler';

ELSIF level ~* 'exception' THEN

   RAISE EXCEPTION  'RAISE EXCEPTION FROM test_error_handler';

END IF;

RETURN TRUE ;

END;
$BODY$
   LANGUAGE 'plpgsql' VOLATILE
|) or die $dh->errstr;

my $sth = $dh->prepare('SELECT * FROM test_error_handler( ? )');
die $sth->errstr if $sth->err;

for my $level (qw/notice warning/){
     $sth->execute($level);
     is( $sth->err, 6, "level $level sets err to 6");
}
for my $level (qw/exception/){
     $sth->execute($level);
     is( $sth->err, 7, "level $level sets err to 7");
}

$sth->finish;

$dh->do('DROP FUNCTION test_error_handler(character varying)')
     or die $dh->errstr;


#######
output:
NOTICE:  RAISE NOTICE FROM test_error_handler
not ok 1 - level notice sets err to 6
#   Failed test 'level notice sets err to 6'
#   at test.pl line 47.
#          got: undef
#     expected: '6'
WARNING:  RAISE WARNING FROM test_error_handler
not ok 2 - level warning sets err to 6
#   Failed test 'level warning sets err to 6'
#   at test.pl line 47.
#          got: undef
#     expected: '6'
DBD::Pg::st execute failed: ERROR:  RAISE EXCEPTION FROM test_error_handler at t
est.pl line 50.
ok 3 - level exception sets err to 7
1..3
# Looks like you failed 2 tests of 3.

$sth->{TYPE} for text column

Mick Brooks — 2011-03-07T16:50:48

Hi,

I recently upgraded DBD::Pg from version 1.49 (that came with Fedora Core 8) to
2.17.2. One of my programs uses the TYPE attribute of statements in exactly the
way suggested in the DBI perldoc for type_info:

---- extract from http://search.cpan.org/~timb/DBI/DBI.pm#type_info ----
For example, to find the type name for the fields in a select statement you can do:

   < at >names = map { scalar $dbh->type_info($_)->{TYPE_NAME} } < at >{ $sth->{TYPE} }
------------------------------------------------------------------------

but this line stopped working for any statements where the results include
a column of PostgreSQL type 'text'. The problem is caused by $sth->{TYPE}
returning -1 for the text column, and then there being no type_info entry
for that value.

I searched around and found a thread in this newsgroup starting at message:

http://www.nntp.perl.org/group/perl.dbd.pg/2007/08/msg162.html

where Greg Sabino Mullane indicates that the change to returning -1 is intentional.
Should there also be a type_info entry so that the code from the DBI documentation
works?

I also found there's at least one other person who has had the same problem:

http://stackoverflow.com/questions/2562587/why-doesnt-dbi-dbdpg-return-the-correct-column-type-for-text-for-my-ad-hoc-q

I now appreciate that $sth->{pg_type} offers a workaround, but I'd prefer it
worked as suggested by the DBI docs if at all possible. Even if you'd prefer
to not change the behaviour, would it be possible to document that the DBI
example code doesn't work, and the reasoning for using a type value of -1?

Thanks for your help,

Mick

$sth->{TYPE} for text column

Mick Brooks — 2011-03-07T17:01:24

Hi,

I recently upgraded DBD::Pg from version 1.49 (that came with Fedora Core 8) to
2.17.2. One of my programs uses the TYPE attribute of statements in exactly the
way suggested in the DBI perldoc for type_info:

---- extract from http://search.cpan.org/~timb/DBI/DBI.pm#type_info ----
For example, to find the type name for the fields in a select statement you can do:

   < at >names = map { scalar $dbh->type_info($_)->{TYPE_NAME} } < at >{ $sth->{TYPE} }
------------------------------------------------------------------------

but this line stopped working for any statements where the results include
a column of PostgreSQL type 'text'. The problem is caused by $sth->{TYPE}
returning -1 for the text column, and then there being no type_info entry
for that value.

I searched around and found a thread in this list starting at message:

http://www.nntp.perl.org/group/perl.dbd.pg/2007/08/msg162.html

where Greg Sabino Mullane indicates that the change to returning -1 is intentional.
Should there also be a type_info entry so that the code from the DBI documentation
works?

I also found there's at least one other person who has had the same problem:

http://stackoverflow.com/questions/2562587/why-doesnt-dbi-dbdpg-return-the-correct-column-type-for-text-for-my-ad-hoc-q

I now appreciate that $sth->{pg_type} offers a workaround, but I'd prefer it
worked as suggested by the DBI docs if at all possible. Even if you'd prefer
to not change the behaviour, would it be possible to document that the DBI
example code doesn't work, and the reasoning for using a type value of -1?

Thanks for your help,

Mick

(Sorry if you receive this twice, finding how to post here was tricky...)

Git and version 3.0

Greg Sabino Mullane — 2011-02-10T22:00:05

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


So all of this UTF-8 work got me thinking about making a 
separate subversion branch for it. Then I remembered I've 
been wanting to move to git (and have talked to some of you 
about it already). It might make sense to make the move 
from subversion to git while we are doing all the other 
major changes. Perhaps we even 'fork' now, and make the 3.0 
release where we switch from subversion to git officially. 
Or to put it another way, our first git release will be 
3.0 :) We'll keep subversion around for any more 2.x 
development (which there will be some of, espeically if 
it takes a while to iron out 3.0). Thoughts? Objections?

- -- 
Greg Sabino Mullane greg-738XdyZ4GzZWk0Htik3J/w< at >public.gmane.org
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201102101657
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAk1UX4kACgkQvJuQZxSWSsg7HgCgsNE1wKRWIaZ89R0+1woUc6G7
E9MAni5sQIMHr1lnj8Of/gvl3LFzpGCu
=4339
-----END PGP SIGNATURE-----