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
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
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 probl
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 internall
On Sat, 28 Nov 2009 00:43:48 +, Tim Bunce
wrote:
> 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
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.
> >
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 t
-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 w
On Tue, Nov 24, 2009 at 02:32:51PM +0100, H.Merijn Brand wrote:
> On Tue, 24 Nov 2009 13:12:24 +, Tim Bunce
> wrote:
>
> > > o test code using all this which demonstrates binding with a type works
> > > and LoosleyTyped and MinMemory do as they should. Some of this will be a
> > > little awkw
On Tue, 24 Nov 2009 13:12:24 +, Tim Bunce
wrote:
> > o test code using all this which demonstrates binding with a type works
> > and LoosleyTyped and MinMemory do as they should. Some of this will be a
> > little awkward to turn into a test that works for everyone as it needs
> > Devel::Peek.
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.
> >
> > Perh
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:
>
>> There was an omission in my addition to Tim's example as I forgot to
>> change DBISTATE_VERSION.
>
> Thanks.
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_
> >> l
Martin Evans wrote:
> 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) wi
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.
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
>> thi
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
-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
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
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) || (v
Just to let you guys know I am following this very closely
Right now I as still pinned down with regular work but hopefully this
week I will get some DBD::Oracle time.
So far I have to agree with Tim about the 'magic numbers'
I think as well as we do a describe before the execute we can get t
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'
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
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
On Mon, Oct 26, 2009 at 03:03:43PM +, Martin Evans 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 holes.
>
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
-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:
>
>> 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. Fo
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. Fo
-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 JSON
Thanks for the reply John.
John Scoles wrote:
> Sounds like an easy patch to DBD::Oracle (off the top of my head) I am
> not sure how it would fix into the DBI spec though.
>
> If I am reading the question right you want to be able to tell
> DBI/DBD::Oracle that col X of a return is an int?
Yes
Sounds like an easy patch to DBD::Oracle (off the top of my head) I am
not sure how it would fix into the DBI spec though.
If I am reading the question right you want to be able to tell
DBI/DBD::Oracle that col X of a return is an int?
something like
$SQL='select my_id,my_name from my_table'
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 SQL_INTEGER (or whatever) so they
loo
33 matches
Mail list logo
