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
Tim Bunce wrote:
Post a diff and I'll review it for you. The code you appended previously
looks ok.
Attached is a diff for DBD::Oracle based on subversion this morning (the
diffs for oci8.c may be a little difficult to read due to the large
indentation of the surrounding code and there are
Apologies if it seems this change is stalled, I've been extremely busy
attempting to keep the wolf from the door. I will be back on it to
finish it in the next few days. I've so far:
o documented change in trunk for bind_col (edited by Tim)
o documented change in trunk for DBI::DBD
o fixed a
On Sat, Nov 28, 2009 at 11:05:31AM +0100, H.Merijn Brand wrote:
Does anyone know if there are other databases that have mapping issues
with
integers and Perlish integers other than Oracle? Just curious, as I only
personally know how a handful deal with ints internally.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I'm mostly settled on DBIstcf_STRICT _not_ being the default.
So 'loosely typed' will be the default and people who want an error
if the type can't be cast safely
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I'm mostly settled on DBIstcf_STRICT _not_ being the default.
So 'loosely typed' will be the default and people who want an error
if the
On Fri, Nov 27, 2009 at 06:03:29PM -, Greg Sabino Mullane wrote:
I'm mostly settled on DBIstcf_STRICT _not_ being the default.
So 'loosely typed' will be the default and people who want an error
if the type can't be cast safely will need to use StrictlyTyped = 1.
I'm sorry for the delay in replying Martin.
On Tue, Nov 10, 2009 at 03:24:33PM +, Martin Evans wrote:
Perhaps it could have been one of those informationals as the sv is
unchanged and still usable but it is not in the requested format so
I'd class that an error.
Perhaps we should
Thread is getting a bit long so I've snipped a lot of previous code.
Tim Bunce wrote:
On Mon, Nov 09, 2009 at 05:05:11PM +, Martin Evans wrote:
Martin Evans wrote:
first patch snipped
There was an omission in my addition to Tim's example as I forgot to
change DBISTATE_VERSION.
Tim Bunce wrote:
On Tue, Oct 27, 2009 at 02:54:43PM +, Martin Evans wrote:
The next question is whether overflowing to an NV should be an error.
I'm thinking we could adopt these semantics for bind_col types:
SQL_INTEGER IV or UV via sv_2iv(sv) with error on overflow
this would be
On Mon, Nov 09, 2009 at 02:43:28PM +, Martin Evans wrote:
I'm presuming you missed a bit off your patch:
Yes, sorry, I was just throwing it out there for discussion of the
general approach/principles. None so far.
Tim.
On Mon, Nov 09, 2009 at 05:05:11PM +, Martin Evans wrote:
Martin Evans wrote:
+/* Convert a simple string representation of a value into a more specific
+ * perl type based on an sql_type value.
+ * The semantics of SQL standard TYPE values are interpreted _very_
loosely
+ * on
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I cannot say why you changed DBD::Pg for JSON::XS but I can say why I
want integers back from Oracle instead of strings when I ask for
integers and the column is an integer. I don't think it is square pegs
into round holes.
Well you'll
On Wed, Oct 28, 2009 at 04:54:06PM -, Greg Sabino Mullane wrote:
I cannot say why you changed DBD::Pg for JSON::XS but I can say why I
want integers back from Oracle instead of strings when I ask for
integers and the column is an integer. I don't think it is square pegs
into round
On Mon, Oct 26, 2009 at 05:29:21PM +, Martin Evans wrote:
What follows is a very rough patch (definitely not finished) which
proves you can do what I wanted to do. However, there on no checks on
the column being bound existing and I'm not sure how to save the TYPE
attribute when bind_col
Thanks Tim for the help on this.
Tim Bunce wrote:
On Mon, Oct 26, 2009 at 05:29:21PM +, Martin Evans wrote:
What follows is a very rough patch (definitely not finished) which
proves you can do what I wanted to do. However, there on no checks on
the column being bound existing and I'm not
On Tue, Oct 27, 2009 at 02:54:43PM +, Martin Evans wrote:
+
+memcpy(zval, p, datalen);
+zval[datalen] = '\0';
+val = strtol(zval, e, 10);
+
+if ((val == LONG_MAX) || (val == LONG_MIN) ||
Tim Bunce wrote:
On Tue, Oct 27, 2009 at 02:54:43PM +, Martin Evans wrote:
+
+memcpy(zval, p, datalen);
+zval[datalen] = '\0';
+val = strtol(zval, e, 10);
+
+if ((val == LONG_MAX) || (val ==
Greg Sabino Mullane wrote:
With reference to the rt I created Support binding of integers so they
are returned as IVs at http://rt.cpan.org/Public/Bug/Display.html?id=49818
If I'm understanding you correctly, this was recently 'fixed' in DBD::Pg,
to accomodate JSON::XS as well. For the
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I could do what DBD::Pg does here (and have to verify it works) but
Oracle integers can be very large - too big to fit in an IV in some
cases.
Greg Sabino Mullane wrote:
I could do what DBD::Pg does here (and have to verify it works) but
Oracle integers can be very large - too big to fit in an IV in some
cases.
Ah yes, I forgot that Oracle doesn't really have an integer
Martin J. Evans wrote:
Hi,
With reference to the rt I created Support binding of integers so they
are returned as IVs at http://rt.cpan.org/Public/Bug/Display.html?id=49818
I am now at the point where being unable to bind columns to results-sets
in DBD::Oracle with a bind type of
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
With reference to the rt I created Support binding of integers so they
are returned as IVs at http://rt.cpan.org/Public/Bug/Display.html?id=49818
If I'm understanding you correctly, this was recently 'fixed' in DBD::Pg,
to accomodate
Greg Sabino Mullane wrote:
With reference to the rt I created Support binding of integers so they
are returned as IVs at http://rt.cpan.org/Public/Bug/Display.html?id=49818
If I'm understanding you correctly, this was recently 'fixed' in DBD::Pg,
to accomodate JSON::XS as well. For the
24 matches
Mail list logo
