Unable to use custom drivers with pyodbc

the libodbc.so.2 from #73 appears to be using unixODBC's defaults which means odbcinst -j produces

DRIVERS............: /etc/odbcinst.ini
SYSTEM DATA SOURCES: /etc/odbc.ini

but since /etc/ isn't modifiable in Lambda, we're stuck with the default MySQL and PostgreSQL drivers. If I wanted to add another driver, I'm out of luck.

After recompiling unixODBC with ./configure --prefix=/var/task/unixODBC, I was able to:

vi /var/task/unixODBC/etc/odbc.ini
vi /var/task/unixODBC/etc/odbcinst.ini
ln -s /var/task/unixODBC/lib/libodbc.so.2.0.0 /var/task/libodbc.so.2

and everything seems to be in order.

I'm a little confused how this package ever worked though, given that with the default configuration:

# Driver from the postgresql-odbc package
# Setup from the unixODBC package
[PostgreSQL]
Description = ODBC for PostgreSQL
Driver    = /usr/lib/psqlodbc.so
Setup   = /usr/lib/libodbcpsqlS.so
Driver64  = /usr/lib64/psqlodbc.so
Setup64   = /usr/lib64/libodbcpsqlS.so
FileUsage = 1

# Driver from the mysql-connector-odbc package
# Setup from the unixODBC package
[MySQL]
Description = ODBC for MySQL
Driver    = /usr/lib/libmyodbc5.so
Setup   = /usr/lib/libodbcmyS.so
Driver64  = /usr/lib64/libmyodbc5.so
Setup64   = /usr/lib64/libodbcmyS.so
FileUsage = 1

none of these files exist in Lambda and neither /usr/lib/ /usr/lib64/ are writable.

@FlipperPA, can you provide any insight here? I'd like to pinpoint what's going on before I submit a PR addressing the issue.

Start by inspecting the packaged libodbc.so.2 and the unixODBC configuration paths reported by odbcinst -j. Compare those paths with Lambda's writable locations and verify that custom odbc.ini and odbcinst.ini files can discover a driver without relying on /etc or unavailable system libraries.