> On Sat 24 Apr 2004 21:38, "Dean Arnold" <[EMAIL PROTECTED]> wrote:
> > I'm finding I frequently need to convert the DBI type metadata
> > from a result set into a string representation (either for display purposes,
> > or to generate additional queries).
> >
> > Is there a need/desire to add a new $sth metadata item
> > TYPE_STRING that would contain that info, eg,
> >
> > $sth->{TYPE}->[0] == SQL_INTEGER => $sth->{TYPE_STRING}->[0] = 'INTEGER'
> > $sth->{TYPE}->[0] == SQL_DECIMAL,
> > $sth->{PRECISION}->[0] == 10,
> > $sth->{SCALE}->[0] == 2 => $sth->{TYPE_STRING}->[0] =
> > 'DECIMAL(10,2)'
> >
> > etc.
> >
> > This appears to be one of those things that could have a default
> > implemention at the DBI layer, but overridden by the driver. This is a bit
> > more convenient than reconstructing things from type_info(), esp. since
> > precision/scale would already be supplied.
> >
> > Since I've coded this translation about a dozen times
> > now, I could probably whip up a patch to DBI for the default.
> > (Probably based on type_info(), if driver provides it, else just
> > a best guess)
> >
> > Opinions ? Have I overlooked something like this thats already in the DBI ?
>
> 1. I like it, and I would use it
> 2. If used to (re)create tables, it would be nice to be able to customize the
> words used in advance, so no changes would be needed afterwords
>
> DECIMAL => NUMBER => NUMERIC => INT2 => BLARGHY => ...
> CHAR => VARCHAR => STRING => HUMBERDREW_4 => ...
> DOUBLE => FLOAT => NUMBER => FLURBLE32 => ...
> DATE => TIME => DATETIME => TIMESTAMP => FIRAGO =>
>
> I've seen too many to be able to stop fantasize about what database designers
> come up with in the future. If I could pass such a table on connect, or assign
> it to a dbh just after, I could use centralized tables. The keys to such table
> could be the current set of SQL_... types, but with fallback enablement for
> generic types (double/float => numeric) optional
>
> --
> H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
> using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
> WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify
> ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
>
>
I'm not entirely certain I understand your request ? My thoughts were as follows:
1) Drivers should provide their own TYPE_STRING values, presumably in their
native platforms' format
2) For any driver that doesn't provide TYPE_STRING, but *does* provide type_info_all(),
DBI layer would generate TYPE_STRING from the information from type_info_all(),
{TYPE}, {PRECISION}, {SCALE}
3) For drivers that provide neither TYPE_STRING nor type_info(), DBI generates
TYPE_STRING from 'standard' type names and {TYPE}/{PRECISION}/{SCALE}
Are you requesting that some master type string "thesaurus" be maintained so
you can do a quick type synonym lookup from one DBMS to another ? As nice
as that might be, its a bit more than I envisioned for this feature, and sortof
exists by just using each DBMS's type_info_all() and translating between them.
Dean Arnold
Presicient Corp.
www.presicient.com
