On Mon, 21 Jan 2019 21:28:43 +0200, Niko Tyni wrote:
> Looks like type_info() now returns more than it used to: with the older
> libdbd-sqlite3-perl it gave just 'undef', but now it gives (somewhat
> unhelpful)
>
> $VAR1 = {
> 'CASE_SENSITIVE' => undef,
> 'MAXIMUM_SCALE' => undef,
> 'NUM_PREC_RADIX' => undef,
> 'MINIMUM_SCALE' => undef,
> 'SQL_DATETIME_SUB' => undef,
> 'NULLABLE' => undef,
> 'LOCAL_TYPE_NAME' => undef,
> 'LITERAL_PREFIX' => undef,
> 'INTERVAL_PRECISION' => undef,
> 'TYPE_NAME' => undef,
> 'DATA_TYPE' => 0,
> 'FIXED_PREC_SCALE' => undef,
> 'AUTO_UNIQUE_VALUE' => undef,
> 'SEARCHABLE' => undef,
> 'UNSIGNED_ATTRIBUTE' => undef,
> 'CREATE_PARAMS' => undef,
> 'COLUMN_SIZE' => undef,
> 'LITERAL_SUFFIX' => undef,
> 'SQL_DATA_TYPE' => undef
> };
>
> I'm not sure how intentional this is, but it seems to have changed
> in DBD-SQLite 1.61_02 as noted in the upstream bug.
>
>
> https://metacpan.org/diff/file?target=ISHIGAKI/DBD-SQLite-1.61_02/&source=ISHIGAKI/DBD-SQLite-1.61_01/I think it's intentional: https://github.com/DBD-SQLite/DBD-SQLite/commit/61e1616c613f2da35e464bdbcfee7b8b2483ca35 (and also https://github.com/DBD-SQLite/DBD-SQLite/issues/36 ) and the returned values of type_info_all() don't look crazy, compared to the commented out example from DBD::Oracle which was in the code before. Why $sth->{TYPE} still doesn't return SQL_<types> is another question … > Checking that the value is defined seems to fix / work around this, > as seen in the attached patch. I'm not totally sure that this > won't break things on other DBD implementations though. I don't think so, if they $info->have {TYPE_NAME} the behaviour shouldn't change … Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Nick Drake: Time Has Told Me
signature.asc
Description: Digital Signature
