On Wed, Dec 31, 2014 at 03:55:42AM -0000, Greg Sabino Mullane wrote: > > Tim Bunce wrote: > > Wherein I attempt to summarize the requirements, the background, the > > options, > > the risks, and the counter-proposal ... > > Thanks for taking the time to write all this out in a coherent manner.
You're welcome. I find the effort usually greatly clarifies my thinking. > I may once again assume the role of devil's advocate herein. Thanks. > > In modern application development, however, the DBI is just another > > foundation layer, low down in the stack. Above it are modules like > > SQL::Abstract, and ORMs like DBIx::Class. Companies have large and > > growing investments in these stacks, plus the modules they've built over > > them to provide abstraction and encapsulation of business logic. > > Agreed. > > > For these large applications the attribute workarounds are rarely helpful. > > Is that a true generalization? Or is it only because these large > applications have not bothered to support the attributes? Supporting attributes means supporting (non-standard) numbered placeholders. Supporting numbered placeholders is, as previously described, very far from trivial for SQL::Abstract and thus DBIx::Class. (I certainly wouldn't characterize this as "not bothered".) > > +Some drivers allow you to prevent the recognition of a placeholder by > > placing a > > +single backslash character (C<\>) immediately before it. The driver will > > remove > > +the backslash character and ignore the placeholder, passing it unchanged > > to the > > +backend. If the driver supports this then L</get_info>(9000) will return > > true. > > Seems a good start. I don't like the phrase "prevent recognition of a > placeholder" > but it's too late at night to propose an alternate right now. s/prevent/disable/? > >> Which likely means that SQL::Abstract and/or DBIx::Class will need to > >> know as well. (Unless they expose the DBD directly to the user, which > >> ruins the point a bit). > > > > Not true. > > How will a user of SQL::Abstract know if escapes are supported or not? > Isn't the job of such frameworks to release the user from such worries, > or at least present some sort of attribute the user can rely on? SQL::Abstract isn't (just) about portability. It allows SQL conditions to be expressed and composed via Perl data structures. That's very powerful functionality. Users who want to use a postgres ? operator know they're using DBD::Pg and can simply require the appropriate version. > > Question marks are the international standard for placeholders. > > The DBI should have specified a way to escape them from the start. > > I'm attempting to fix that now. > > Taking off the devil's advocate hat now. I can agree with this > position and the backslash solution. Great. Thanks Greg. > > To demonstrate the relative complexity, here's a proof-of-concept patch > > for DBD::Pg to implement support for escaping question mark placeholders: > > > > https://github.com/timbunce/dbdpg/commit/54358c7a7efeeaf2666c5e28c301e47624fb9615 > > +1, thanks for that. I certainly cannot see any harm in adding escape support > to DBD::Pg, and then letting the upstream modules start adapting to it. Wonderful. I'll work on polishing up the patch. Tim.
