Re: Escaping placeholders, take 2

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.