On Mon 26 Apr 2004 17:31, "Dean Arnold" <[EMAIL PROTECTED]> wrote:
> > 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
>
> 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}
This is more clear to me, and I think it covers my request.
Thanks for the extra explanation
> 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.
--
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/
