Not quite. It knows if the perl scalar value has numeric and/or
string representations cached (the SvPOK and SvINOK flags).
Getting those back would be enough to handle the quoting
issue. I can pass '0' as a value from perl into an sth
and SOME sort of conversion is done on the way in that
allows the database to deal with it as a number. I can
also pass in 0 + 0 and have it stringified for insertion
into a varchar2. This is a huge benefit in data handling
but makes dealing with error messages a pain because the
support people don't want to paste-and-quote-ify each
of the placeholder values by hand if I spew out sql with
placeholders and some values in my error message.
I don't see how anything keyed by NAME could help with anything
related to placeholders.
For placeholders the ParamValues attribute exists already and
I've also previously talked about adding a ParamAttribs attribute.
I can look up the names from the query. Last time I brought
this up hashed results seemed to be the answer. For my part
an array of database-requires-stringy would be ideal.
Plus, the paramvalues comes as a hash, not an array
(though a vector of placeholders properly quoted would
make error message reporting simpler):
"ShowErrorStatement" (boolean, inherited)
...
If "$h->{ParamValues}" returns a hash reference of
parameter (placeholder) values then those are format-
ted and appended to the end of the Statement text in
the error message.
DBI::looks_like_number() would be better, for some definition of better.
Problem is numeric char sequences. I may have to
store "0" in a varchar.
my $sql = "insert into table( blah blah blah ) values ( ?, ?, ? )";
my $insert = $dbh->prepare( $sql );
...
eval { $insert->execute( @_ ) };
if( $@ )
{
# oops. support folk don't want to paste values into
# the '?' by hand. trick now is to convert the '?'
# into properly quoted values so that they can
# cut+paste the result directly into their database
# interface for testing why the query had problems.
my @needsquotz = $insert->SvTypes;
my $revised = $sql;
for my $value ( @_ )
{
$field = qq{'$field'} if shift @needsquotz;
$revised = s/\?/$field/;
croak <<"END";
Roadkill: unable to execute insert:
$revised;
Due to:
$@
END
}
}
All this does is replace '?' with properly quoted values.
The ONLY reason this is really necessary is handling
digit-strings, which "look" numeric but are stored as
numbers. This is a serious problem in the financial
industry, as they habitually store monitary amounts as
strings to avoid rounding issues. Sybase -- the database
in place where I ran across this issue -- does not gracefully
handle converting a naked 0 to "0" for insertion into a
stringy field (usually a varchar2).
Given a decent way of getting the stringy behavior (and
a flag of SvPOK vs. SvINOK would work) I could easly write
DBIx::PlaceHolderFill to convert sql + the arguments into
a pasteable representation of the data.
enjoi
--
Steven Lembark 85-09 90th Street
Workhorse Computing Woodhaven, NY 11421
[EMAIL PROTECTED] 1 888 359 3508
