Re: Is there a way to avoid having the library slurp-read th

Ruby
1

Hi depesz,

I’ve looked for things like that, but it doesn’t seem like they’ve been
exposed in the Ruby API. If I try to make a DBI prepared statement, it
will just slurp-read the first time I call execute on it. The native
PostgreSQL-extension doesn’t seem to have any classes for cursors or
prepared statements, and neither does the pure Ruby version.

Does anyone know if ActiveRecord might be a solution? Does it have it’s
own implementation of a PostgreSQL connector?

Helge E.

2

2006/8/4, Helge E. [email protected]:

I’ve looked for things like that, but it doesn’t seem like they’ve been
exposed in the Ruby API. If I try to make a DBI prepared statement, it
will just slurp-read the first time I call execute on it. The native
PostgreSQL-extension doesn’t seem to have any classes for cursors or
prepared statements, and neither does the pure Ruby version.

Hm, I wonder why would you need special API for that?
PGconn.exec should be sufficient:

require ‘postgres’
c = PGconn.new
c.exec(“BEGIN”)
c.exec(“DECLARE my_curs CURSOR FOR SELECT * FROM
generate_series(1,20000)”)
while (rs = c.exec(“FETCH FORWARD 1000 FROM my_curs”)) &&
rs.num_tuples > 0
rs.each { |r| print r[0], “,” }
rs.close
end
c.exec(“CLOSE my_curs”)
c.exec(“COMMIT”)

Does anyone know if ActiveRecord might be a solution? Does it have it’s
own implementation of a PostgreSQL connector?

ActiveRecord just uses ruby-postgres or postgres-pr libs

3

Does anyone know if ActiveRecord might be a solution? Does it have it’s
own implementation of a PostgreSQL connector?

I’m on thin ice here, but a quick browsing of the postgresql_adabter.rb
in
AR reads:

if @async
@connection.async_exec(sql)
else
@connection.exce(sql)
end

(lines 162…166)

So, it seems to me that AR would not solve your problem. Maybe one could
patch it with the sub-slurp posted in this thread.

4

On Sat, 5 Aug 2006, Jon Egil S. wrote:

else
@connection.exce(sql)
end

(lines 162…166)

So, it seems to me that AR would not solve your problem. Maybe one could
patch it with the sub-slurp posted in this thread.

indeed - i sent a patch in some time ago to address this - but no joy.

-a

5

On 8/5/06, Jon Egil S. [email protected] wrote:

So, it seems to me that AR would not solve your problem. Maybe one could
patch it with the sub-slurp posted in this thread.

I’ve found that AR exacts such a high price in performance that I
write applications using both AR and a native driver. I use AR for all
the lightweight stuff (for the productivity benefits), and code
against the native adapter for everything heavy, like the query that
is the subject of this thread. Even using AR’s capabilities for
directly executing raw SQL code is measurably slower than using the
underlying adapters. You do lose portability across database engines
with this approach, but high performance in any database generally
requires a lot of engine-specific tunings anyway.