Re: CPAN indexer (was Re: DBD::Pg CVS version.)
On Sun, Nov 24, 2002 at 08:30:43PM +, Tim Bunce wrote: On Sat, Nov 23, 2002 at 03:39:48PM -0700, Jason E. Stewart wrote: Hey Tim, Tim Bunce [EMAIL PROTECTED] writes: On Sat, Nov 23, 2002 at 12:53:39AM -0700, Jason E. Stewart wrote: Thomas A. Lowery [EMAIL PROTECTED] writes: The first thing I noticed is perl Makefile.PL croaked because I didn't have an App::Info ... module installed. IMHO, this should be removed as it is not part of DBI nor truly required by the DBD::Pg. I'm not sure of the status of this. I believe David was integrating App::Info into a private directory to only be used by the configuration process. Should be included under the t/ directory to stop the CPAN indexer seeing it. Is t/ the only directory? It would be nice to leave t/ for tests. Is the indexer documented someplace? I was having trouble with it parsing the version number of one of my modules. I don't know about the indexer on PAUSE, but search.cpan.org does not look inside t/ but it does index all other modules it finds. Graham.
Re: DBD::Pg - a strong request
I've found pg_config the best solution to determine where things are
installed.
pg_config provides information about the installed version of PostgreSQL.
Usage: pg_config --bindir | --includedir | --includedir-server | --libdir |
--pkglibdir | --configure | --version
Operation modes:
--bindir show location of user executables
--includedir show location of C header files of the client
interfaces
--includedir-server show location of C header files for the server
--libdir show location of object code libraries
--pkglibdir show location of dynamically loadable modules
--configure show options given to 'configure' script when
PostgreSQL was built
--version show the PostgreSQL version and exit
However, on that note, just installing the darn module may not be possible
without skipping the tests.
There are additional pieces of information needed:
$ENV{DBDPG_TEST_DB}
$ENV{DBDPG_TEST_HOST}
$ENV{DBDPG_TEST_USER}
$ENV{DBDPG_TEST_PASS}
(prevents mucking up a real database)
Other DBD::* modules require DBI_DSN, DBI_USER, DBI_PASS to run the
tests. Without the correct setup installing from CPAN will fail.
Tom
Report bugs to [EMAIL PROTECTED].
On Sun, Nov 24, 2002 at 04:33:15PM -0600, Dave Rolsky wrote:
On Sun, 24 Nov 2002, Randal L. Schwartz wrote:
Jason Absolutely. It is one of the first things that was discussed. The
Jason decision was to use App::Info during the configuration phase.
Well, I hope it just falls back to doing the right thing if the lib
and include file are found in the same places Perl looks for
everything else.
Don't ask questions. Just install the darn module.
It looks for pg_config, which if found will tell it what it needs. I'd
prefer that it ask questions rather than the current irritating approach
of just giving up completely, though.
--
Thomas A. Lowery
See DBI/FAQ http://xmlproj.dyndns.org/cgi-bin/fom
Sourceforge for DBD driver
On Thu, Nov 21, 2002 at 10:47:03AM -0700, Jason E. Stewart wrote: Given the ability to get free time/space on servers like sourceforge or even perl.org, why is this still the case? I'm really happy that I've already registered dbd-xbase on sourceforge for DBD::XBase but I really didn't find time to study all the necessary details to manage the thing there. Especially, I'd like to start with uploading all the previous versions (which I hold as a series of tar.gz's) to sourceforge to form CVS ... but without external help I'm affraid I won't be able to do it. Are there any CVS/sourceforge knowledgable people out there who would like to help me with this? -- Honza Pazdziora | [EMAIL PROTECTED] | http://www.fi.muni.cz/~adelton/ ... all of these signs saying sorry but we're closed ...
Re: DBD::Pg - a strong request
On Monday, November 25, 2002, at 08:46 AM, Thomas A. Lowery wrote: I've found pg_config the best solution to determine where things are installed. pg_config is exactly what App::Info::RDBM::PostgreSQL uses to set up the library paths. However, on that note, just installing the darn module may not be possible without skipping the tests. Up to now, DBD::Pg has pretty much just skipped the tests. I think that the tests need to be extensively rewritten to change that. Other DBD::* modules require DBI_DSN, DBI_USER, DBI_PASS to run the tests. Without the correct setup installing from CPAN will fail. Yes, I'd like to see DBD::Pg start to use a more standard and comprehensive test suite. Needless to say, I plan such a thing for the new version I'm working on. But that's going to be a while in the making... Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: DBD::Pg - a strong request
Thomas A. Lowery [EMAIL PROTECTED] writes:
There are additional pieces of information needed:
$ENV{DBDPG_TEST_DB}
$ENV{DBDPG_TEST_HOST}
$ENV{DBDPG_TEST_USER}
$ENV{DBDPG_TEST_PASS}
(prevents mucking up a real database)
Other DBD::* modules require DBI_DSN, DBI_USER, DBI_PASS to run the
tests. Without the correct setup installing from CPAN will fail.
Given that the other modules standardize around the DBI_* variables,
I'm happy to change the existing DBD::Pg test to use this.
jas.
Re: Escaping Binary Data in DBD::Pg
On Sunday, November 24, 2002, at 05:30 PM, Bruce Momjian wrote:
I think he is saying mention is as depricated in the current driver,
and
remove it when you release your major revision of the driver.
Okay, I've made this change. Here's my commit message:
date: 2002/11/25 22:52:20; author: theory; state: Exp;
Added constants for common PostgreSQL data types, plus simple tests to
make
sure that they work. These are exportable via use DBD::Pg
qw(:pg_types);. Documented deprecatation of the undocumented (and
invalid)
use of SQL_BINARY in bind_param() and documented the correct approach:
bind_param($num, $val { pg_type = PG_BYTEA });. Removed invalid (and
broken) support for SQL_BINARY in quote().
=
Use of the bind_param($num, $val, SQL_BINARY) syntax still works,
however, and doesn't throw a warning. Should it?
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
RE: DBD::Pg - a strong request
Other DBD::* modules require DBI_DSN, DBI_USER, DBI_PASS to run the
tests. Without the correct setup installing from CPAN will fail.
The most recent versions of DBD::ODBC's tests, however, gracefully handle
DBI_DSN being undefined for just this purpose (and ActiveState's repository
builds, too).
In the BEGIN block, code such as what's below helps allow CPAN and
ActiveState's binary repository build run without the environment set. Of
course this doesn't help if the ODBC driver manager is not there, but what's
below is probably the best compromise.
unless (defined $ENV{DBI_DSN}) {
print 1..0 # Skipped: DBI_DSN is undefined\n;
exit;
}
Regards,
Jeff
Re: CPAN indexer (was Re: DBD::Pg CVS version.)
On Monday, November 25, 2002, at 03:13 PM, Graham Barr wrote: If the inclusion of modules in distributions is common and t/ is not acceptable then a common place should be agreeded. I almost suggested this recently with the release of CPAN::MakeMaker which depends on . being in @INC. But it has the side affect that everyone will have CPAN::MakeMaker in thier dist on search. Works for me. How 'bout inc/? David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Anybody using $h-event(...) and DBIh_EVENT*() ?
They're about to be deprecated/changed/removed or something as
part of moving towards a $h-{HandleEvent} = sub { ... } interface.
So far I've just gutted the DBIh_EVENT*() macros so they do nothing
(old drivers may use them at the point they set err errstr but the
DBI never did much with them).
Tim.
Re: Anybody using $h-event(...) and DBIh_EVENT*() ?
On Monday, November 25, 2002, at 03:26 PM, Tim Bunce wrote:
They're about to be deprecated/changed/removed or something as
part of moving towards a $h-{HandleEvent} = sub { ... } interface.
So far I've just gutted the DBIh_EVENT*() macros so they do nothing
(old drivers may use them at the point they set err errstr but the
DBI never did much with them).\
Naturally, DBD::Pg uses DBIh_EVENT2 in a couple of places:
DBIh_EVENT2(h, ERROR_event, DBIc_ERR(imp_xxh),
DBIc_ERRSTR(imp_xxh));
But I imagine we can purge these, if necessary.
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: CPAN indexer (was Re: DBD::Pg CVS version.)
On Mon, Nov 25, 2002 at 03:09:40PM -0800, David Wheeler wrote: On Monday, November 25, 2002, at 01:49 AM, Graham Barr wrote: Is t/ the only directory? It would be nice to leave t/ for tests. Is the indexer documented someplace? I was having trouble with it parsing the version number of one of my modules. I don't know about the indexer on PAUSE, but search.cpan.org does not look inside t/ but it does index all other modules it finds. Okay, I'm moving it all into t/lib, but that means that I now have this in Makefile.PL: use lib 't/lib'; This ain't portable, of course. I can use File::Spec, but then it becomes required, too, and would likely have to be included in the distribution, since Makefile.PL will use it before it uses WriteMakefile(PREREQ_PM). It has been in the core since 5.6.0, IIRC. How do people feel about this? And to load the File::Spec module you've supplied you'll need a use lib :-) I'd just hack in the very few alternatives you need (/ + Max + VMS, you can ignore windows as / works fine) in a BEGIN block. Tim.
Re: CPAN indexer (was Re: DBD::Pg CVS version.)
On Monday, November 25, 2002, at 03:34 PM, Tim Bunce wrote: And to load the File::Spec module you've supplied you'll need a use lib :-) Heh, good point. I'd just hack in the very few alternatives you need (/ + Max + VMS, you can ignore windows as / works fine) in a BEGIN block. Um, what is it on VMS? Never mind, I can look in File::Spec::VMS. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Escaping Binary Data in DBD::Pg
On Mon, Nov 25, 2002 at 02:58:41PM -0800, David Wheeler wrote:
On Sunday, November 24, 2002, at 05:30 PM, Bruce Momjian wrote:
I think he is saying mention is as depricated in the current driver,
and
remove it when you release your major revision of the driver.
Okay, I've made this change. Here's my commit message:
date: 2002/11/25 22:52:20; author: theory; state: Exp;
Added constants for common PostgreSQL data types, plus simple tests to
make
sure that they work. These are exportable via use DBD::Pg
qw(:pg_types);. Documented deprecatation of the undocumented (and
invalid)
use of SQL_BINARY in bind_param() and documented the correct approach:
bind_param($num, $val { pg_type = PG_BYTEA });. Removed invalid (and
broken) support for SQL_BINARY in quote().
=
Use of the bind_param($num, $val, SQL_BINARY) syntax still works,
however, and doesn't throw a warning. Should it?
If it doesn't work then yes (if $h-{Warn} is set, see Driver.xst for examples).
Tim.
Re: $sel-CursorName does not exist
On Monday, November 25, 2002, at 04:04 PM, Tim Bunce wrote:
Perl 5.8.0 is (quite reasonably) clearing refs in lexical variables
in a more timely manner when the sub exists.
The failing test in 07kids.t isn't testing anything significant
so I've just replaced it with a comment:
# Testing $dbh-{Kids} here is unstable because we would be
relying on
# when perl chooses to call DESTROY the lexical $sth created
within prepare()
# The HandleError sub doesn't get called until the do() is
returning
# and recent perl's (=5.8.0) have destroyed the handle by then
(quite reasonably).
# When a HandleEvent attribute gets added to the DBI then we'll
probably call that
# at the moment the error is registered, and so we could test
$sth-{Kids} then.
Ah, how interesting. Makes sense.
Um, what is HandleEvent? Have you described it somewhere?
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
