develooper Front page | perl.perl5.porters | Postings from March 2000

Re: hook for qs// operator for embedded SQL?

Joseph N. Hall
March 20, 2000 09:20
Re: hook for qs// operator for embedded SQL?
Message ID:
On Mon, 20 Mar 2000 08:59:40 -0600 (Greg Bacon) wrote:

* In message <>,
*     "Joseph N. Hall" writes:
* :
* : Here, @cols needs to be ,-separated, $table and $col need one kind of
* : interpolation, and $val needs another.  It's certainly not unreasonable
* : to assume that a future qs// could be smart enough to recognize this
* : much SQL.
* Do DBI placeholders handle that sort of thing?  How hard would it be to
* extend them to do so?  Then your only hurdle would be syntactical.

Placeholders don't have any context-sensitive quoting aspect that I'm
aware of at present.  Adding enough to be useful might or might not
be difficult.  As long as the approach is basically pattern-matching and
NOT parsing of the "SQL" (which varies radically from vendor to vendor),
I think that would be manageable.

Some sort of clever "rules dictionary" that says "array name to the right
of select is expanded with commas," "array name inside VALUES() list
is quoted and expanded with commas," etc. is one thing I think might
work.  This really doesn't have anything to do with Perl guts EXCEPT
that it might be nice if the access to interpolative stringification 
that currently exists through overload were MUCH finer grained.  So 
perhaps for "$a @b $c[$d]" you'd get three separate calls, each with

  * thing being interpolated (globref or value ref)
  * context/position in string
  * anything else relevant (?)

Something like this based on the guts of Perl is very important, because
only Perl knows how to parse the guts of a double-quoted string.

Obviously this capability would be useful to many things other than
something like embedded SQL.

* What sorts of expectations are you finding?  What sorts of complaints
* do people have about using DBI?

The OO syntax and the DSNs and the like are obstacles.  In general the
clients should rely more on environment variables and a non constructor
oriented syntax would be less of a barrier.  "Should" meaning if the
point is to make DBI more accessible.  It's already reasonably versatile,
even if it basically lacks cursors and type integration.

  -joseph Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About