On 2/11/06, Greg Sabino Mullane <[EMAIL PROTECTED]> wrote:
> DBI currently supports sending "NULL" values by using an undef.
> I'd like to propose a mechanism to support another "non-value"
> value, "DEFAULT". Since we've already overloaded simple scalar
> values with use of the undef, the only option I see is to use
> a scalar ref. Specifically, I'd like to propose that a new variable,
> e,g, $DBI::DEFAULT_VARIABLE, be used to indicate a literal value
> of 'DEFAULT' for those databases that support such a thing. This
> would be a small blessed object (thanks to Max Cohan for suggesting
> that instead of a my earlier hashref idea). Drivers would simply
> check if the value passed to execute was a ref, then
> (if ref $value =~ /DBI::Default/) it would use a literal DEFAULT
> instead of a quoted variable.
>
> In other words:
>
> my $foo = "yin";
> my $foo = "yang";
>
> $sth = $dbh->prepare("INSERT INTO mytable(a,b,c,d) VALUES (?,?,?,?)");
> $sth->execute($foo, $bar, undef, $DBI::DEFAULT_VARIABLE);
>
> would send this to the backend:
>
> INSERT INTO mytables(a,b,c,d) VALUES ('yin','yang',NULL,DEFAULT);
>
> And likewise for bind_param, etc.
>
And for those DBMS that do not support the DEFAULT notation? Who does the
fallback work? DBI? The driver? If the latter, I oppose - probably even
if you make it absolutely crystal clear what the fallback semantics are.
--
Jonathan Leffler <[EMAIL PROTECTED]> #include <disclaimer.h>
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
"I don't suffer from insanity - I enjoy every minute of it."
