On 11/04/2010 06:00 AM, Tim Bunce wrote:
> On Wed, Nov 03, 2010 at 09:13:38PM -0400, Rudy Lippan wrote:
>>
>> Hi Tim, &al.,
>>
>> I am working on writing a DBD for mongoDB, but before I get too far into
>> the code, I'd like to get an official prefix fo
On 11/03/2010 10:08 PM, Darren Duncan wrote:
> Darren Duncan wrote:
>> Rudy Lippan wrote:
>>> Does anyone know if there are any DBD::drivers that do not use some
>>> variant of SQL? I ask because I am planing on implementing the driver
>>> using mongoDB&#x
Hi Tim, &al.,
I am working on writing a DBD for mongoDB, but before I get too far into
the code, I'd like to get an official prefix for it. I am leaning
towards 'hu_'* this way I won't have to worry about any of my names
colliding with anything that is using a mongo_, although dbdmongodb_ or
mon
On 11/27/2009 01:03 PM, Greg Sabino Mullane wrote:
> I'd opine that since we're dealing with databases holding Important Things,
> the default should be to throw an error and make people flip a switch
> to get lax mode. A large warning in the upgreade notes should suffice for
> anyone tr
On Fri, 15 Apr 2005, Tim wrote:
> > #define foobar rows
> > void
> > foobar(sth)
> > SV* sth
> > CODE:
> > ...
> >
> > The above should make subpp happy and should get rid of the dup function
> > warning.
>
> I suspect that won't work, sadly, as xsubpp uses the name to generate
> some C co
On Fri, 15 Apr 2005, Patrick Galbraith wrote:
> What about how to deal with returning values (my_ulonglong) that are
> larger than the default defined value of dbd_st_rows from DBI (int) ?
Well, in Driver.xst (mysql.xst) dbd_st_rows returns void and sticks an SV
on the stack, in this case the
On Fri, 15 Apr 2005, Philip M. Gollucci wrote:
> >#ifdef false
> >void dbd_st_rows() {...}
> >#endif
> >
> >
> newer compiles should also optimize: particularly gcc
>
> if (false) {
> }
>
> out
>
Maybe I am missing something here, but what does optimizing out if blocks have
to do with
On Thu, 14 Apr 2005, Patrick Galbraith wrote:
> Tim,
>
> For the longest time, there's been this annoying warning with the
> compile for DBD::mysql:
>
> cc -c -I/Library/Perl/5.8.1/darwin-thread-multi-2level/auto/DBI/
> -I/usr/local/mysql/include -fno-omit-frame-pointer
> -DDBD_MYSQL_INSERT_
On Tue, 14 Dec 2004, Tim Bunce wrote:
> On Tue, Dec 14, 2004 at 02:54:39PM +0900, [EMAIL PROTECTED] wrote:
> > Hi.
> Assuming that the "40% faster" relates mainly to fetching then
> here's a quick review of the relevant code...
>
> While the DBD::Pg extension does:
>
> for(i = 0; i < num_
Hello everyone,
DBD::mysql 2.9005_3 should now be up on CPAN.
Changelog:
2004-10-27 Rudolf Lippan <[EMAIL PROTECTED]> (2.9005_3)
* Removed requirement that mysql.mtest be included in the distribution.
* DBI 1.43 is required -- It is needed for support of
$dbh->last_
I just revied the ParamValues docs, and it reminded me of a question I had
WRT ParamValues and prepared statements.
The docs say:
It is possible that the values in the hash returned by "ParamVal-
ues" are not exactly the same as those passed to bind_param() or
e
On Thu, 25 Mar 2004, Tim Bunce wrote:
> Date: Thu, 25 Mar 2004 16:05:43 +
> Yeap, bug. But I think it should be:
>
> + last_insert_id => { U =>[5,6,'$catalog, $schema, $table_name, $field_name [,
> \%attr ]'], O=>0x2820 },
>
I missed that one, sorry.
> p.s. I'd recommend using s
Tim,
I ran into some problems with last_insert_id() while trying to implement
it for DBD::mysql 3.0. I have subjoined a patch against DBI 1.42 with the
changes that I made so that I could get last_insert_id() working from the
DBD.
Thoughts, suggestions?
Rudy.
diff -ru DBI-1.42/dbd_xsh.h DBI-
On Fri, 20 Feb 2004, Tim Bunce wrote:
> On Fri, Feb 20, 2004 at 10:30:44AM -0500, Rudy Lippan wrote:
> >
> > - Rewrote the primary_key_info() and primary_key() methods to
> > cleanly handle multi-column primary keys. Also
the
foreign_key_info() method [Greg Sabino Mullane]
- a fetch on any column that had a type that did not have an entry
in the type_info array would segfault DBD::Pg.
(CPAN bugs #4818,4432) [Rudy Lippan]
- Duplicate rows bug with column_info()
Hey all,
I have been pretty much offline for the past 2 weeks or so because of an
illness in the family so that is why I have not been responding to any
DBD::mysql/DBD::Pg related email (actually any email whatsoever). I will
be sorting through spam and answering email tomorrow.
Rudy
DBD::Pg 1.31 is out and on CPAN.
Changes:
1.31 Mon Nov 17 21:21:21 UTC 2003
- $dbh->{TYPE} now returns SQL_TYPE_TIMESTAMP instead of 1114 for
timestamp columns. (In 1.31_x {x| x<8} $sth->{TYPE} returned 0
but reported by ["Hirche, Joachim"
<[EMAIL PROTECTED]>]).
On 30 Oct 2003, Jason E. Stewart wrote:
> Hi,
>
> I've added your patch to GBorg.
>
FYI, this should already be in CVS. And in the the beta versions up on
CPAN; the latest beta being 1.31_7.
Rudy
On Thu, 30 Oct 2003, Tim Bunce wrote:
> Er, I don't follow you. I sent you the code to colum_info and it's
> already in DBD::mysql.
>
table_info, table_info() At least that is what I wrote on my
white-board; I don't what I was thinking when I wrote that...
And If I am still not remembering co
On Wed, 29 Oct 2003, Tim Bunce wrote:
> On Tue, Oct 28, 2003 at 04:39:59PM -0500, Rudy Lippan wrote:
> > >
> > > Also, I am taking requests for features to be added in the next version of
> > > DBD::mysql; The list, as of right now, is:
> > >
> >
DBD::mysql 2.9003 has been uploaded to CPAN.
There are the changes in 2.9003:
2003-10-26 Rudy Lippan <[EMAIL PROTECTED]> (2.9003)
* Applied patch from Aaron and Chuck that added basic testing of
the
table_info/column_info functions [Aaron Ross
<[EMAIL
Try II, from the right address this time :(
On Tue, 28 Oct 2003, Rudy Lippan wrote:
>
> DBD::mysql 2.9003 has been uploaded to CPAN.
>
>
> There are the changes in 2.9003:
>
> 2003-10-26 Rudy Lippan <[EMAIL PROTECTED]> (2.9003)
> * Applied patch f
On Fri, 24 Oct 2003, Jim Cromie wrote:
> Jim Cromie wrote:
>
> From reading the DBI pod, its apparent that the specific capabilities
> of ? vary:
>
> some DBDs support them as column values only,
> most dont allow them as table-names,
> most require value to match entire column
>
On Sat, 27 Sep 2003, Tim Bunce wrote:
> I think this would be okay:
>
> if (SvROK(sv) && !SvAMAGIC(sv) {
> ...error...
> }
> string = SvPV(sv, len);
>
Adding the !SvMAGIC(sv) worked nicely, thank you.
One question: What is the difference between SvMAGIC and SvMAGICAL? And
d
On Wed, 24 Sep 2003, Tim Bunce wrote:
>
> On Tue, Sep 23, 2003 at 08:39:34PM +0100, Tony Bowden wrote:
> > On Tue, Sep 23, 2003 at 11:56:26AM +, Dominic Mitchell wrote:
> > > However, when you attempt to access one of the non-PK columns, it blows
> > > up:
> > > print $pref->value, "\n";
Good day,
DBD::Pg 1.31_5 is now on CPAN.
The last(?) blocker was fixed by Jeremy Yoder, and Mark Stosberg was kind
enough to bundle up this version.
http://search.cpan.org/CPAN/authors/id/R/RU/RUDY/DBD-Pg-1.31_5.tar.gz
Please try this version and report back to the list if you have any
proble
On Thu, 14 Aug 2003, David Wheeler wrote:
> On Thursday, August 14, 2003, at 01:15 PM, Rudy Lippan wrote:
>
> >> Switching to connect_cached() seems to have made my problem with
> >> Apache
> >> 1.3.28 go away Yay! Oh, and BTW, I am doing cleanup by running
On Thu, 14 Aug 2003, David Wheeler wrote:
>
> On Thursday, August 14, 2003, at 11:39 AM, David Wheeler wrote:
>
> >> Caching can be useful in some applications, but it can also cause
> >> problems and should be used with care. The exact behaviour of this
> >> method is liable to change, so if
On Wed, 13 Aug 2003, David Wheeler wrote:
> On Wednesday, August 13, 2003, at 02:03 PM, Rudy Lippan wrote:
>
> > What version of DBD::Pg are you using for this test? Version of
> > mod_perl?
>
> 1.30 from CVS a couple of weeks ago, but I've seen it with 1.22, t
On Thu, 14 Aug 2003, Matt Sergeant wrote:
> On Wednesday, Aug 13, 2003, at 22:46 Europe/London, Perrin Harkins
> wrote:
>
> > My idea would be to leave Apache::DBI as it is for use with legacy CGI
> > code and then add a new module to the distribution that is called
> > explicitly so it has no "
On Wed, 13 Aug 2003, David Wheeler wrote:
> >> You can see that this gets really ugly. Anyone seen anything like
> >> this,
> >> or have any idea what could be causing these problems?
> >
> > Try changing your ping method or removing the ping and see if the
> > problem persists.
>
> Not sure I w
On Wed, 13 Aug 2003, David Wheeler wrote:
> On Wednesday, August 13, 2003, at 12:32 PM, David Wheeler wrote:
>
> > I'm attempting to isolate the problem now.
>
What version of DBD::Pg are you using for this test? Version of mod_perl?
> The code that's causing the hangup looks like this:
>
> o
On Wed, 6 Aug 2003, Paul Makepeace wrote:
> On Mon, Aug 04, 2003 at 01:30:46PM -0400, Rudy Lippan wrote:
> > On Mon, 4 Aug 2003, David Wheeler wrote:
> >
> > > Begin forwarded message:
> > >
> > > > From: Paul Makepeace
> > > >
> >
On Fri, 27 Jun 2003, Cosimo Streppone wrote:
> Rudy Lippan wrote:
> > >
> > > Cosimo Streppone wrote:
> > >
> > I am sure that there is a bug somewhere, but it seems to be fairly
> > isolated; I am just worried about what happens when people try
On Thu, 26 Jun 2003, Cosimo Streppone wrote:
> Hi Rudy,
>
> I saw your last post on dbi-dev regarding your request of a
> backtrace file (25/06 04:26). I already received such a post and I replied
> to you on 25/06 10:56.
>
I know. My email has been a bit screwey this past few days -- Changed
On Thu, 12 Jun 2003, Cosimo Streppone wrote:
>
> I'm not using the default RH perl. I'm including here the full `perl -V`.
I can't seem to get get DBD::Pg to die. Do you think you could give me a
backtrace from the core file?
ulimit -c 1000
make test
gdb -c core.xxx /usr/local/bin/perl
(gdb)
On Mon, 23 Jun 2003, Tim Bunce wrote:
> > 2003-06-22 Rudy Lippan <[EMAIL PROTECTED]> (2.9001)
> > * Added attribute 'auto_reconnect' that allows the auto reconnect
>
> Shouldn't that be mysql_auto_reconnect?
Yup that is what it shoul
, I expect to upload this to CPAN on Tuesday
afternoon (EST).
You can pick up a copy here:
http://www.remotelinux.com/rlippan/DBD-mysql-2.9001.tar.gz
TIA,
Rudy
Changes:
2003-06-22 Rudy Lippan <[EMAIL PROTECTED]> (2.9001)
* moved pod into mysql.pm from mysql.pod
* Chang
On Wed, 11 Jun 2003, Tim Bunce wrote:
> Date: Wed, 11 Jun 2003 12:23:54 +0100
> > DBD::mysql is packaged as a bundle. When I do a release, will I also need
> > to bump the version number on the bundle?
>
> Yes, but the Makefile.PL says
>
> 'VERSION_FROM' => 'lib/DBD/mysql.pm'
>
> so it'l
On Thu, 12 Jun 2003, Cosimo Streppone wrote:
> Date: Thu, 12 Jun 2003 14:59:30 +
> Hi Rudy,
>
Hi Cosimo,
First off, Thank you!
> here is the result of my tests, with either DBI 1.35 and 1.37
> and Postgresql version 7.3.3.
> I'm having several problems with the test scripts.
That is good!
Tim,
DBD::mysql is packaged as a bundle. When I do a release, will I also need
to bump the version number on the bundle?
TIA,
Rudy
On Tue, 10 Jun 2003, David Wheeler wrote:
> Date: Tue, 10 Jun 2003 18:41:42 -0700
> From: David Wheeler <[EMAIL PROTECTED]>
> To: Rudy Lippan <[EMAIL PROTECTED]>
> Cc: 'DBI developers' <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
> [EMAIL PROTECTED]
On Tue, 10 Jun 2003, David Wheeler wrote:
> Date: Tue, 10 Jun 2003 18:21:13 -0700
> From: David Wheeler <[EMAIL PROTECTED]>
> To: Rudy Lippan <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED],
> 'DBI developers' <[EMAIL PROTECTED]>,
DBD::Pg 1.30 is nearing release, and you can grab a copy of the latest
beta at: http://www.remotelinux.com/rlippan/DBD-Pg-1.30_2.tar.gz There
are many changes in this release and large chunks of code have been
re-written, so I would appreciate if some of you could pound on this and
let me kno
On Mon, 9 Jun 2003, Tim Bunce wrote:
> On Mon, Jun 09, 2003 at 01:11:18AM -0400, Rudy Lippan wrote:
> > And now I remember why I did not create an attribute for it.
> > CLINET_FOUND_ROWS is a connect-time option, so it does no good to create a
> > dbh attribute to change th
On Fri, 6 Jun 2003, Tim Bunce wrote:
> On Fri, Jun 06, 2003 at 02:56:12PM -0400, Rudy Lippan wrote:
> > On Fri, 6 Jun 2003, Tim Bunce wrote:
> >
> > >
> > > On a vagely related topic, I think mysql_client_found_rows=1 should
> > > also be the defau
On Fri, 6 Jun 2003, Tim Bunce wrote:
> On Fri, May 30, 2003 at 12:13:17PM -0400, Rudy Lippan wrote:
> > On Thu, 29 May 2003, Tim Bunce wrote:
> >
> > > > Right now this attribute defaults to
> > > > ON for backward compat
On Fri, 6 Jun 2003, Bruce Momjian wrote:
> Date: Fri, 6 Jun 2003 01:03:49 -0400 (EDT)
> From: Bruce Momjian <[EMAIL PROTECTED]>
> To: Tom Lane <[EMAIL PROTECTED]>
> Cc: Rudy Lippan <[EMAIL PROTECTED]>, David Wheeler <[EMAIL PROTECTED]>,
> Domin
On Fri, 30 May 2003, Tom Lane wrote:
> Rudy Lippan <[EMAIL PROTECTED]> writes:
> > On Thu, 29 May 2003, David Wheeler wrote:
> >>>> disabled until PREPARE works a little better
> >>
> >> Pity. Do you know if it will work as well as you need in 7.
On Thu, 29 May 2003, Tim Bunce wrote:
> > List of Changes:
> >
> > * Updated type_info_all() to be more inline with
> > what DBD::ODBC returns.
> > * Added attribute 'auto_reconnect' that allows the auto reconnect
> > behaviour to be toggled.
>
> That should b
On Thu, 29 May 2003, Dominic Mitchell wrote:
> >
> > And for anyone who is interested here is the change log:
>
> One more thing for the change log: notice messages generated by the
> database now use the perl warning mechanism instead of going to stderr,
> so they can be trapped if needed.
>
On Thu, 29 May 2003, David Wheeler wrote:
> > statement,
> > then rewrites the statement as 'EXECUTE "DBD::PG::cached_query n"
> > ($1, $2, ... $n, $n+1)' for DBD::Pg's execute. -- Currently
> > disabled
> > until PREPARE works a little better
>
> Pity. Do you know if it will wo
On Mon, 26 May 2003, Bruce Momjian wrote:
> Rudy, where are we on the release of DBD:pg withs your patches? Are
> they ready to go?
I spun an ALPHA copy of DBD::Pg. So much has changed in there that I am
sure something is broken for someone; therefore, I think we should let
people hammer on it
Hello all,
I have put together a *BETA* release of DBD::mysql, and I would like to
get some feedback esp. WRT any breakage/bugs. If things look good I will
go ahead and release this as 2.1027.
The tarball is here:
http://www.remotelinux.com/rlippan/DBD-mysql-2.1027_2.tar.gz
List of
On Wed, 26 Mar 2003, Bruce Momjian wrote:
>
> Oops, too late. 1.22 packaged and released on gborg, soon CPAN. Feel
> free to start on 1.30 and we can take our time. There were enough fixes
> in CVS head that we needed to get a release out.
>
Yeah, there were some bugs in the patches -- the ar
On Wed, 26 Mar 2003, Bruce Momjian wrote:
> OK, so you are saying that the code as exists now in CVS is ready for
> release, and once we release, you want to add a lot of stuff, right?
> And there is nothing that needs work _before_ we do a release?
Bruce,
1.21 + UTF-8 patch should be ready to
On Wed, 26 Mar 2003, David Wheeler wrote:
> On Wednesday, March 26, 2003, at 07:47 PM, Rudy Lippan wrote:
>
> > So I guess what I am propsing is get 1.22 out (if we even think it is
> > needed -- I think that we can just get away with putting the UTF-8
> > stuff
>
1_30 over HEAD 1_21, then apply
the subsequent patches over that.
Thoughts?
Rudy
> ---
>
> Rudy Lippan wrote:
> > On Fri, 14 Mar 2003, Bruce Momjian wrote:
> >
> > >
> > > To answ
On Fri, 14 Mar 2003, Bruce Momjian wrote:
>
> To answer your question from a month ago :-), we should have CVS tagged
> the 1.21 release, but we forgot. I didn't think we were big enough to
> tag things. :-)
Bruce,
To respond to your message of a week or so ago :-)
I tagged it up a while ago
On Mon, 24 Mar 2003, Paul DuBois wrote:
> At 12:52 + 3/24/03, Tim Bunce wrote:
> >On Mon, Mar 24, 2003 at 12:04:13AM -0500, Rudy Lippan wrote:
> > >and '/', '\', and '.' can not be used in a
> >> quoted identifier. Should
On Fri, 14 Mar 2003, Tim Bunce wrote:
> > get_info needs implementing. DBI::DBD::Metadata is best for that.
> >
Very Nice. :) Though, it looks like the output needs quite a bit of help
in the way of picking off of the mysql struct and such :(
> > quote_identifier needs implementing. (Or you co
On Wed, 19 Mar 2003, Tim Bunce wrote:
> >
> > Can you resend? I did not seem to get the attachment?
>
> Oops, forgot. Attached. I've tweaked it slightly to use quote_identifier(),
> which I'm presuming you're supporting (probably via adding get_info() data).
>
> Some of the CHAR_SET_* and COLLAT
On Tue, 18 Mar 2003, Tim Bunce wrote:
> > 2. When you get a chance, could you send me your column info patch, so
> > that I can apply it before mucking too with the perl code?
>
> Attached.
>
Can you resend? I did not seem to get the attachment?
> > Also looking at the auto reconenct, I think
On Mon, 3 Mar 2003, Tim Bunce wrote:
> $sth = $dbh->prepare("SELECT table.field FROM table"); # note table.field
> $sth->execute;
> print "NAME_lc = '$sth->{NAME_lc}->[0]' \n";
>
> for the drivers you use?
>
> Is it 'field' or 'table.field'?
For DBD::Pg I get field.
> If it's 'table.fiel
On Wed, 26 Feb 2003, Tim Bunce wrote:
> > I know there is a {NUM_OF_PARAMS} attribute and a {ParamValues} attribute,
> > but is there a way to get the names of :foo style params before they are
> > bound?
>
> Umm, not officially currently but there's a good chance that keys
> %{$sth->{ParamValues
On Wed, 26 Feb 2003, Tim Bunce wrote:
> Clarified documentation for ParamValues attribute hash keys.
I know there is a {NUM_OF_PARAMS} attribute and a {ParamValues} attribute,
but is there a way to get the names of :foo style params before they are
bound?
-r
On Tue, 25 Feb 2003, H.Merijn Brand wrote:
> On Tue 25 Feb 2003 10:27, Tim Bunce <[EMAIL PROTECTED]> wrote:
> > On Mon, Feb 24, 2003 at 07:41:54PM -0500, Rudy Lippan wrote:
> > >
> > > If 5005, does it have unicode support or should the unicode
> > >
Tim,
I was about to check in a UTF-8 patch for DBD::Pg when I realized that I
did not know when perl got unicode support. I know that 5.8 has support
and that 5.6 has some unicode support, but I do not know about 5005. So
what is the min. version of perl that you want DBD drivers to support,
On Fri, 21 Feb 2003, Tim Bunce wrote:
> Jochen Wiedmann has told me he's interested in finding someone
> to take over the development and maintainance of DBD::mysql.
>
> Anyone interested?
If no one else is interested, I will volunteer -- From playing with
DBD::Pg, I think I am starting to get
On Thu, 13 Feb 2003, Dominic Mitchell wrote:
> Well at the moment, backwards compatibility is limited to one system at
> our place that needed the funtionality right now. We'll change it to
> use whatever DBD::Pg comes with, however.
Right, but once it goes into a public release (eg. DBD::Pg 1
On Wed, 12 Feb 2003, David Wheeler wrote:
> On Wednesday, February 12, 2003, at 08:45 PM, Rudy Lippan wrote:
>
> > Just did a quick look a the patch and the Pgsql docs. I need to do
> > some
> > more research, but what do you think about a set_client_encoding()
> &
On Wed, 12 Feb 2003, David Wheeler wrote:
>
> On Wednesday, February 12, 2003, at 08:49 PM, Bruce Momjian wrote:
>
> > Let's get the small UTF patch into a DBD:pg release, then we can just
> > put it all into the main CVS and do a beta/final release with his
> > changes. I don't see why we nee
On Wed, 12 Feb 2003, David Wheeler wrote:
> On Wednesday, February 12, 2003, at 07:42 PM, Rudy Lippan wrote:
>
> Oh, well we can create a branch for the old version. Bruce, do you have
> a CVS tag convention that you like to use?
>
> > As for CPAN, should I go ahead set
On Wed, 12 Feb 2003, Dominic Mitchell wrote:
>
> David Wheeler wrote:
> > On Tuesday, February 11, 2003, at 10:51 PM, Rudy Lippan wrote:
> >> Known problems with patch:
> >>
> >> 1. Broke new pg_bool_tf attribute.
> >
> >
> > Ah. Can
On Wed, 12 Feb 2003, David Wheeler wrote:
>
> > I'd like to start putting together some developer releases (set up a
> > cvs
> > branch for this?), and see about getting together a stable release
> > version
> > that addresses the all of the outstanding problems with DBD::Pg.
> >
> > So, if pe
On Thu, 6 Feb 2003, David Wheeler wrote:
> Unfortunately I have no time to work on DBD::Pg stuff right now. :-(
> I'll have to rely on others to evaluate your approach. Post to the
> dbi-dev list, too -- those folks have a better idea on how to implement
> DBI drivers, I think.
>
> I hope I ca
I just happend upon this message while catching up on pgsql-interfaces...
On Thu, 23 Jan 2003, David Wheeler wrote:
> Date: Thu, 23 Jan 2003 17:31:11 -0800
> From: David Wheeler <[EMAIL PROTECTED]>
> To: Kaare Rasmussen <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: [INTERFACES] Prep
On Wed, 11 Dec 2002, Bruce Momjian wrote:
> PQescapeString is not for binary data, only for text string, escaping
> quotes and backslashes and stuff like that. The only binary one is
> PQescapeBytea().
Makes sense.
What exactly is Pg's idea of binary data? Anything !in SQL_CHARACTER ||
!in in L
On Wed, 11 Dec 2002, David Wheeler wrote:
> > Because libpq is C based, and we pass the query as a C string to the
> > backend, I can not think of a way to make nulls pass transparatenly.
> > Seems bytea is the only good solution, where \\0 becomes NULL.
>
> Yeah, but now we're talking about what
> 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 muc
On Thu, 21 Nov 2002, Tim Bunce wrote:
>
> Or ignore colons that have a digit as the previous character
> as that would never be a placeholder.
>
Since DBD::Pg emulates place holders, it is possible to have them after a
digit.
I thought that using the [ as a literal marker might break less exis
On Thu, 21 Nov 2002, Adam Witney wrote:
> One thing you may want to keep in mind is the situation concerning array
> slices
>
> If you send a statement like this
>
> my $sth = $dbh->prepare("select cube[1:2][1][1] from test4");
>
> Then the :2 gets treated as a placeholder and gets substituted.
On Wed, 20 Nov 2002, David Wheeler wrote:
>
> >> Maybe it's just too complex, because, looking at DBD::ODBC's
> >> dbd_preparse(), the handling of literals in the query seems a good
> >> deal
> >> more straight-forward (though it doesn't appear to handle '\'' or "\""
> >> -- am I reading that ri
On Wed, 20 Nov 2002, Tim Bunce wrote:
> > Maybe it's just too complex, because, looking at DBD::ODBC's
> > dbd_preparse(), the handling of literals in the query seems a good deal
> > more straight-forward (though it doesn't appear to handle '\'' or "\""
> > -- am I reading that right?
>
> ANSI
On Wed, 20 Nov 2002, Tim Bunce wrote:
> > I notice that
> > DBD::ODBC, for example, doesn't appear to do anything special with
> > regard to comments. And if comments *are* supported by DBI, and DBD::Pg
> > is doing the right thing by watching out for them, wouldn't it be
> > smarter for DBD::
On Mon, 18 Nov 2002, David Wheeler wrote:
> With feedback from Tom Lane, I think I'll add code to track when to
> BEGIN a transaction, and check it in execute() to see if it needs to be
> turned on before executing a statement.
>
I thought about that, but I was thinking that it would add quite
On Sun, 17 Nov 2002, David Wheeler wrote:
> * In DBD::Pg's dbdimp.c, the dbd_db_commit() function attempts a
> commit, and if it's successful, it then starts another transaction. Is
> this the proper behavior? The other DBDs I looked at don't appear to
> BEGIN a new transaction in the dbd_db_co
On Tue, 29 Oct 2002, Tim Bunce wrote:
> That seems like a rather poor design.
>
I take it you have worked with PostgreSQL much :)
> Beware that your semantics for SQL_BINARY must match those of ODBC.
> I think ODBC requires SQL_BINARY values to be formated as pairs of
> hex chars.
So you are
On Mon, 28 Oct 2002, David Wheeler wrote:
> Yes, that was my guess, too. But since ' shouldn't be double-escaped
> with , I would say that quote() doesn't work with binary data.
>
The extra quotes are a result of passing quoted data to execute(), not
any problem with quote() itself; it jus
On Sat, 26 Oct 2002, David Wheeler wrote:
> But the real solution is the one Rudy suggested. The appearance of the
> single quotes around data escaped by quote() is there because the
> method is designed for quoting data you wish to use inline in a SQL
> statement, not with placeholders. Thus,
On Thu, 24 Oct 2002, David Wheeler wrote:
> >
> > Good question. Probably, but then it should be calling the libpq
> > functions when available. And quoting should be made to understand
> > text[]
> > types, also (getting them out, is a complately different problem).
>
> Actually, I think that
On Thu, 24 Oct 2002, David Wheeler wrote:
> > Whoops, my bad. Indeed the first method increases the file size by a
> > couple bytes, guess I wasn't paying enough attention.
>
> Not sure how that happens, but I'd be happy to see quote() replaced
> with calls to the appropriate libpq routines.
>
On Wed, 23 Oct 2002, David Wheeler wrote:
> Okay, the problem is that DBD::Pg's execute() method doesn't call
> quote() for the parameters passed to it. So quote() is never called for
> your code. The good news is that you don't have to base64 encode your
> binary data. Instead, call the quote(
On Mon, 21 Oct 2002, David Wheeler wrote:
> I think that part of the misunderstanding comes out of the different
> cultures of the PostgreSQL and Perl communities. The PostgreSQL
> developers have no maintainer, no Pumpking, no Poobah. They work
> together on issues that interest them, come to
On 6 Mar 2002, Jeffrey W. Baker wrote:
> I don't like this patch. It looks like it could walk off the beginning
> of a string. Also I'm not certain if I understand the problem. I
> assume that you want to do:
>
> SELECT foo FROM bar WHERE baz = \'?
>
> Is that correct? I'm having a hard tim
On 6 Mar 2002, Jeffrey W. Baker wrote:
> Given I've been unable to contact Mr. Mergl on his own terms and given
> DBD::Pg is unreliable, unbuildable, and generally in a bad condition, I
> propose to make the next release of DBD::Pg myself.
>
> Several users have mailed patches to me or to this l
On Thu, 10 Jan 2002, Tim Bunce wrote:
> > 1) Why do you have the character class as a-z and not A-Z?
>
> Note the 'i' in /.../i.
>
> > 2) quote_identifier(["this", "is a ",test],1) would return q{this."is a
>".test}
>
> I think you haven't tried it :)
>
Remind me to never to respond
Tim,
On Thu, 10 Jan 2002, Tim Bunce wrote:
> >
> > Seems non-trivial to me...
>
> No. The SQL should have been constructed by the application calling
> quote_identifier() on any identifiers it contains.
>
> The issue is how your DBD's quote_identifier implementation knows
> whether it should
98 matches
Mail list logo
