From: Norbert Buchmuller Date: Tue, 17 Feb 2009 19:34:50 +0000 (+0000) Subject: Added documentation of the impact of bindtype on \[$sql, @bind]. X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=deb148a247cc54b629b582a8b446ff905f0efb90;p=scpubgit%2FQ-Branch.git Added documentation of the impact of bindtype on \[$sql, @bind]. --- diff --git a/lib/SQL/Abstract.pm b/lib/SQL/Abstract.pm index dc28d48..89eb37d 100644 --- a/lib/SQL/Abstract.pm +++ b/lib/SQL/Abstract.pm @@ -1382,6 +1382,10 @@ are or are not included. You could wrap that above C loop in a simple sub called C or something and reuse it repeatedly. You still get a layer of abstraction over manual SQL specification. +Note that if you set L to C, the C<\[$sql, @bind]> +construct (see L) +will expect the bind values in this format. + =item quote_char This is the character that a table or column name will be quoted @@ -1875,6 +1879,14 @@ This would create: $stmt = "WHERE ( date_column = date '2008-09-30' - ?::integer )" @bind = ('10'); +Note that you must pass the bind values in the same format as they are returned +by C. That means that if you set L to C, you must +provide the bind values in the C<< [ column_name => value ] >> format, so eg. +the above example will look like: + + my %where = ( + date_column => \[q/= date '2008-09-30' - ?::integer/, [ dummy => 10 ]/] + ) Literal SQL is especially useful for nesting parenthesized clauses in the main SQL query. Here is a first example :