[ruby-dbi-users] dbd_pg and deallocating prepared statements

KUBO Takehiro kubo at jiubao.org
Sat Sep 6 09:59:54 EDT 2008

Sorry so long.

> Even though this is the case, the problem still exists that the statement will
> attempt to deallocate on a disconnected database. While that check can be done
> in the finalizers, I'd like to see support at a higher level for this kind of
> operation; statements shouldn't exist when corresponding database handles
> don't, and so on.

When deallocating on a disconnected database, "not connected"
exception is raised. But an exception in GC is ignored. So nobody need
to rescue it. I had to add a comment to the patch about this, but I
omitted it...

> The current situation (where Pg is the only DBD distributed with DBI that does
> server-side prepared statements) is the result of poor support in the DBDs
> that work against databases with prepared statement support.

Ruby-oci8 also supports prepared statement, but it manages statement
handles by itself. IMO, MySQL, DB2, ODBC, SQL Server, SQLite are also
similar. PostgreSQL's prepared statement is quite unique.

> Using finalizers is not the issue I'm attempting to address here, it's an
> implementation detail of the problem, which is that #finish must be called
> explicitly right now, and both of us agree that it shouldn't be necessary.
> What we disagree on is where this should be handled, or more precisely, what's
> the path that's taken to define these handlers.

I think that it should be done when more than two dbd drivers
(including currently unsupported) are expected to need finalizers.
I'm not against you. I'm just concerned that if no dbd except dbd_pg
use it, it makes dbi complex more than needs.

More information about the ruby-dbi-users mailing list