Hello,
For the ruby-postgres users out there, I would like to announce the
coming of a 0.8.0 release. First, some wider spread testing would be
a good idea. The current gem is version 0.7.1.2005.11.27. This is
basically 0.8.0 RC1 (can you do "RC1" type versioning with gems?).
What''s new:
- bug and leak fixes (get_notify works)
- bind parameters (postgresql uses $1, $2, etc)
- Win32 binary gem
- results translated to ruby classes (old behavior of string results
is available with PGconn::translate_results = false)
- rows are: PGrow < Array; behave like hash, ex row[''id'']
or row.each
{|column,value| ...} and row.to_hash
- rdocs (more work needed)
- simplified build
- open/connect/new with connection string or hash
New methods:
- escape_bytea/unescape_bytea
- on_notice
- transaction_status
- server_version, protocol_version
- lastval (only available when connected to postgresql >= 8.1)
- oid
feel free to let me know if you find any bugs. feature requests are welcome.
Dave
Dave Lee wrote:>Hello, > >For the ruby-postgres users out there, I would like to announce the >coming of a 0.8.0 release. First, some wider spread testing would be >a good idea. The current gem is version 0.7.1.2005.11.27. This is >basically 0.8.0 RC1 (can you do "RC1" type versioning with gems?). > >What''s new: > >- bug and leak fixes (get_notify works) >- bind parameters (postgresql uses $1, $2, etc) >- Win32 binary gem >- results translated to ruby classes (old behavior of string results >is available with PGconn::translate_results = false) >- rows are: PGrow < Array; behave like hash, ex row[''id''] or row.each >{|column,value| ...} and row.to_hash >- rdocs (more work needed) >- simplified build >- open/connect/new with connection string or hash > >New methods: > >- escape_bytea/unescape_bytea >- on_notice >- transaction_status >- server_version, protocol_version >- lastval (only available when connected to postgresql >= 8.1) >- oid > > >Which Postgres is this, DBI or postgres-pr? Or, is there another one? I am working on an extension to postgres-pr, but it could be easily adapted another one. I am adding methods to build a cursor, and do fetches rather than build one big array. Large tables (several million rows) kill the machine when it comes to memory usage if you need to use the whole thing (batch processing). I would like to eventually get it to the point wheer it could be usefulas an ETL tool.
On 12/1/05, Grant Johnson <grant-ousXCV6JwGd54TAoqtyWWQ@public.gmane.org> wrote:> Which Postgres is this, DBI or postgres-pr? Or, is there another one?another one. this extension requires the libpq postgresql client library. DBI uses this extension to provide postgresql support.> I am working on an extension to postgres-pr, but it could be easily > adapted another one. I am adding methods to build a cursor, and do > fetches rather than build one big array.I haven''t tested the code below, but the postgres extension should be capable of operating this way via the declare/fetch postgresql commands. conn = PGconn.open(''dbname'' => ''whatever'') conn.exec(''DECLARE foo_cursor CURSOR FOR select * from foo_table'') result = conn.exec(''FETCH 10 FROM foo_cursor'') # or result = conn.exec(''FETCH NEXT FROM foo_cursor'') conn.exec(''CLOSE foo_cursor'') Dave