Update src/core/session.cpp

Backend is not set properly with connection pool
Patch for SOCI/soci#46 to support readying bytea data in PostgreSQL
fix to build the Firebird backend on Ubuntu
Merge pull request #56 from vnaydionov/master

Fix to build the Firebird backend
Added License section
fixed sqlite3 test
Properly compute LIBDIR on (modern) Debian

While Fedora considers "lib" and "lib64" reasonable settings for LIBDIR[1]
the Debian people dismissed that setup in favor of a more scalable
approach[2]. They install libraries to lib/${arch}-linux-gnu.

This patch addresses that difference.

1: http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks
2: https://wiki.ubuntu.com/MultiarchSpec#Filesystem_layout
Merge remote-tracking branch 'upstream/master'
Merge remote-tracking branch 'snikulov/fix_for_15' into issue-15
Typo
Linked Wiki and FAQ on front page
Merge remote-tracking branch 'upstream/master' into issue-15
Update to Sergei Nikulov's fix for issue #15

Clarify supported sequence of statement::execute(false|true) and
statement::get_affected_rows() calls across all backends:
1. execute(false) and empty destination does not execute statement, but
prepares for subsequent statement::fetch() requests.
2. execute(true)  and empty destination calls requests backend to
execute statement.
3. execute(false|true) causes bulk fetch to destination, with
withDataExchange=false|true ignored.
Moved relevant test to common tests, confirmed it passes for all but
Oracle (get_affected_rows not implemented) and Firebird (I have no means
to test).
Related discussion at
http://sourceforge.net/mailarchive/message.php?msg_id=30312517
Thanks to Sergei who first proposed this behaviour as reliable and
consistent option, yet not intrusive.
Merge remote-tracking branch 'upstream/master'
Update to Sergei Nikulov's fix for issue #15

Clarify supported sequence of statement::execute(false|true) and
statement::get_affected_rows() calls across all backends:
1. execute(false) and empty destination does not execute statement, but
prepares for subsequent statement::fetch() requests.
2. execute(true)  and empty destination calls requests backend to
execute statement.
3. execute(false|true) causes bulk fetch to destination, with
withDataExchange=false|true ignored.
Moved relevant test to common tests, confirmed it passes for all but
Oracle (get_affected_rows not implemented) and Firebird (I have no means
to test).
Related discussion at
http://sourceforge.net/mailarchive/message.php?msg_id=30312517
Thanks to Sergei who first proposed this behaviour as reliable and
consistent option, yet not intrusive.
Merge remote-tracking branch 'hobu/issues/46-bytea-read-for-postgis' into issue-46
PostgreSQL test for bytea - #46. Use case of bytea to dt_string mapping is unclear, so it needs to be confirmed if the ida is to allow the semantic as presented in the test_bytea() that data != (bin1 == bin1).
Fix Ubuntu detection at build configure stage
Build Firebird backend using patch from Sergei Nikulov
Firebird backend: Fix into() binding for 64bit integers