ruby-dbi-devel — ruby-dbi development list

Re: [Ruby-DBI-devel] Is rows reliable for SELECT statements?

[Michael N. <uu...@rz...>]

Paul DuBois wrote:
> Use of $sth->rows in Perl DBI is discouraged for obtaining a row count
> from SELECT statements, do to the fact that not all drivers return the
> row count reliably until all the rows have been fetched (if at all).
> Instead, the docs recommend counting the rows as you fetch them.
> 
> Does the same apply to Ruby DBI?

Statement#rows does not return the number of rows in the result set!
Instead it returns the RPC (Row Processed Count) which is only valid
for DELETE/UPDATE.

But depending on the DBD it may also work with SELECT statements.

Regards,

  Michael

Re: [Ruby-DBI-devel] DBI.trace - does it work?

[Paul D. <pa...@sn...>]

At 13:03 +0100 1/20/03, Michael Neumann wrote:
>Paul DuBois wrote:
>>  I am assuming that DBI.trace can be used to set the global trace
>>  level for a script, but it appears not to be doing what I expect.
>>
>>  For example, in the DBI distribution, examples/trace_test.rb begins like
>>  this:
>>
>>  require "dbi"
>>  require "dbi/trace"
>>
>>  DBI.trace(0)
>>
>>  dbh = DBI.connect('dbi:Mysql:database=test')
>>
>>
>>  However, when I run the script, I get trace output from the connect
>>  call, even though the global level is set to 0.  (The DBI docs don't
>>  specify so, but I assume 0 = "off".)  Output is:
>
>0 = No Tracing at all.
>
>
>>  % ruby trace_test.rb
>>  -> connect for #<DBI::DriverHandle:0x184148> ("database=test", nil, nil,
>>  nil)
>>  !! Access denied for user: 'paul@localhost' (Using password: NO)
>>  <- connect for #<DBI::DriverHandle:0x184148>
>>  /usr/lib/ruby/site_ruby/1.6/DBD/Mysql/Mysql.rb:66:in `connect':
>>  Access denied for user: 'paul@localhost' (Using password: NO)
>>  (DBI::DatabaseError)
>>          from /usr/lib/ruby/site_ruby/1.6/dbi/dbi.rb:550:in `connect'
>>          from (eval):8:in `connect'
>>          from /usr/lib/ruby/site_ruby/1.6/dbi/dbi.rb:367:in `connect'
>>          from trace_test.rb:6
>>
>
>I get the following:
>
>/usr/local/lib/ruby/site_ruby/1.6/DBD/Mysql/Mysql.rb:66:in 
>`connect': Can't connect to local MySQL server through socket 
>'/tmp/mysql.sock' (2) (DBI::DatabaseError)
>         from /usr/local/lib/ruby/site_ruby/1.6/dbi/dbi.rb:550:in `connect'
>         from (eval):8:in `connect'
>         from /usr/local/lib/ruby/site_ruby/1.6/dbi/dbi.rb:367:in `connect'
>         from trace_test.rb:6
>
>
>Which version of AspectR are you using? Try the newest (0.3.5).
>
>
>Regards,
>
>   Michael

Hm.  I am using AspectR 0.3.5.

My versions are:

Ruby MySQL module 2.4.3c
Ruby DBI 0.0.18
AspectR 0.3.5

I modified the script to be a little simpler (and to connect successfully).


require "dbi"
require "dbi/trace"

DBI.trace(0)
dbh = DBI.connect('dbi:Mysql:database=test', 'paul','somepass')
dbh.disconnect

I'd expect no output at all from the script , but this is what I get:

% ruby trace_test.rb
-> connect for #<DBI::DriverHandle:0x1842b0> ("database=test", 
"paul", "somepass",
nil)
<- connect for #<DBI::DriverHandle:0x1842b0> = #<DBI::DatabaseHandle:0x173dfc>
-> disconnect for #<DBI::DatabaseHandle:0x173dfc> ()
<- disconnect for #<DBI::DatabaseHandle:0x173dfc> = nil

If I modify it so that the trace level is 1, 2, or 3, the trace output
is identical.  Seems odd.

I get the same results on Mac OS X and on RedHat 7.0 (other than that the
object addresses are different, of course).

Anything I can do to figure out what's going on here?

Setting the trace level on database or statement handles seems to work
correctly, it's just that setting the global level doesn't have any effect.
Thanks.

Re: [Ruby-DBI-devel] DBI.trace - does it work?

[Michael N. <uu...@rz...>]

Paul DuBois wrote:
> I am assuming that DBI.trace can be used to set the global trace
> level for a script, but it appears not to be doing what I expect.
> 
> For example, in the DBI distribution, examples/trace_test.rb begins like
> this:
> 
> require "dbi"
> require "dbi/trace"
> 
> DBI.trace(0)
> 
> dbh = DBI.connect('dbi:Mysql:database=test')
> 
> 
> However, when I run the script, I get trace output from the connect
> call, even though the global level is set to 0.  (The DBI docs don't
> specify so, but I assume 0 = "off".)  Output is:

0 = No Tracing at all.


> % ruby trace_test.rb
> -> connect for #<DBI::DriverHandle:0x184148> ("database=test", nil, nil, 
> nil)
> !! Access denied for user: 'paul@localhost' (Using password: NO)
> <- connect for #<DBI::DriverHandle:0x184148>
> /usr/lib/ruby/site_ruby/1.6/DBD/Mysql/Mysql.rb:66:in `connect': 
> Access denied for user: 'paul@localhost' (Using password: NO) 
> (DBI::DatabaseError)
>         from /usr/lib/ruby/site_ruby/1.6/dbi/dbi.rb:550:in `connect'
>         from (eval):8:in `connect'
>         from /usr/lib/ruby/site_ruby/1.6/dbi/dbi.rb:367:in `connect'
>         from trace_test.rb:6
> 

I get the following:

/usr/local/lib/ruby/site_ruby/1.6/DBD/Mysql/Mysql.rb:66:in `connect': Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) (DBI::DatabaseError)
        from /usr/local/lib/ruby/site_ruby/1.6/dbi/dbi.rb:550:in `connect'
        from (eval):8:in `connect'
        from /usr/local/lib/ruby/site_ruby/1.6/dbi/dbi.rb:367:in `connect'
        from trace_test.rb:6


Which version of AspectR are you using? Try the newest (0.3.5).


Regards,

  Michael

[Ruby-DBI-devel] Article: Using the Ruby DBI Module

[Paul D. <pa...@sn...>]

I've written an article, "Using the Ruby DBI Module," that discusses
using Ruby DBI to write programs that access databases.  The article 
is available here:

     http://www.kitebird.com/articles/


I'd be interested in feedback, especially corrections if there
are errors.

The article follows an earlier one, "Using the Ruby MySQL Module,"
that describes the lower-level module on which the Ruby DBI MySQL
driver is based.  The earlier article is available at the same site.

[Ruby-DBI-devel] DBI.trace - does it work?

[Paul D. <pa...@sn...>]

I am assuming that DBI.trace can be used to set the global trace
level for a script, but it appears not to be doing what I expect.

For example, in the DBI distribution, examples/trace_test.rb begins like
this:

require "dbi"
require "dbi/trace"

DBI.trace(0)

dbh = DBI.connect('dbi:Mysql:database=test')


However, when I run the script, I get trace output from the connect
call, even though the global level is set to 0.  (The DBI docs don't
specify so, but I assume 0 = "off".)  Output is:

% ruby trace_test.rb
-> connect for #<DBI::DriverHandle:0x184148> ("database=test", nil, nil, nil)
!! Access denied for user: 'paul@localhost' (Using password: NO)
<- connect for #<DBI::DriverHandle:0x184148>
/usr/lib/ruby/site_ruby/1.6/DBD/Mysql/Mysql.rb:66:in `connect': 
Access denied for user: 'paul@localhost' (Using password: NO) 
(DBI::DatabaseError)
         from /usr/lib/ruby/site_ruby/1.6/dbi/dbi.rb:550:in `connect'
         from (eval):8:in `connect'
         from /usr/lib/ruby/site_ruby/1.6/dbi/dbi.rb:367:in `connect'
         from trace_test.rb:6



What am I not understanding here?

[Ruby-DBI-devel] Is rows reliable for SELECT statements?

[Paul D. <pa...@sn...>]

Use of $sth->rows in Perl DBI is discouraged for obtaining a row count
from SELECT statements, do to the fact that not all drivers return the
row count reliably until all the rows have been fetched (if at all).
Instead, the docs recommend counting the rows as you fetch them.

Does the same apply to Ruby DBI?

Re: [Ruby-DBI-devel] Question about select_one method

[Michael N. <uu...@rz...>]

Paul DuBois wrote:
> In dbi.rb, select_one is defined like this:
> 
> 
>   def select_one(stmt, *bindvars)
>     raise InterfaceError, "Database connection was already closed!" 
> if @handle.nil?
>     row = nil
>     execute(stmt, *bindvars) do |sth|
>       row = sth.fetch
>     end
>     row
>   end

Method execute calls cancel (and finish) of sth.

Regards,

  Michael

[Ruby-DBI-devel] Question about select_one method

[Paul D. <pa...@sn...>]

In dbi.rb, select_one is defined like this:


   def select_one(stmt, *bindvars)
     raise InterfaceError, "Database connection was already closed!" 
if @handle.nil?
     row = nil
     execute(stmt, *bindvars) do |sth|
       row = sth.fetch
     end
     row
   end



Should this invoke cancel after invoking fetch, to clobber the result
set, in case there are more rows than one and fetch doesn't invoke
cancel implicitly?

[Ruby-DBI-devel] Connecting w/o specifying database name

[Paul D. <pa...@sn...>]

The MySQL driver for Ruby DBI appears to *require* that you specify
a database name when connecting.  Is this part of the DBI spec itself
(if so, I don't see it), or some quirk of the MySQL driver?

I ask because there are perfectly good reasons to connect with no
database name, e.g., if you just want to query the server for general
status information.  Perl DBI allows the database name to be unspecified.

Re: [Ruby-DBI-devel] merry christmas! (+ some thoughts..)

[Michael N. <uu...@rz...>]

Elias Karakoulakis wrote:
> Hello all and merry christmas!
> 
> I am in the process of extending the IBM DB2 driver and I have to put 
> forward some points that I came across while working with DBI:
> 
> 1) Memory management in DBI should be rethought of. The DBI layer should 
> be lenient as to its usage by client apps, which means that calls like 
> Statement.finish or Database.disconnect should always do their thing 
> (free C buffers, close log files, turn off the coffee machine etc.) 
> regardless of their being called by the user script or not. For 
> instance, the following hypothetical script leaks like hell:
> 
>    while [some boolean]
>        st = db.prepare([some sql])
>        st.execute([some values])
>    end
> 
> Yes, I know this is not the 'proper' way to use DBI (suppose I never 
> heard of 'Database.do'). But DBI should at least it should try to invoke 
> "st.finish unless st.finished?" in a finalizer closure if a statement 
> object is finalized without having freed its internal resources. The 
> same applies to database connections and other environment handles. I 
> don't know if the use of finalizers is the correct way to address the 
> problem, so I expect your thoughts on this.

This is easy to accomplish in an C extension (where the GC calls a free 
function).  In Ruby, you have to use finalizers, which are slow and ugly.

Currently most database drivers are just wrappers around some existing 
database interfaces. This approach is slow and requires more memory, and   
things like you mentioned above are harder to implement.

I am currently planning "Ruby/DBI Next Generation", which should
solve many problems (especially performance but also memory related).
But due to very spare free time, there will be no release in the next
months.

Merry Christmas!

Regards,

  Michael

[Ruby-DBI-devel] merry christmas! (+ some thoughts..)

[Elias K. <ek...@na...>]

Hello all and merry christmas!

I am in the process of extending the IBM DB2 driver and I have to put 
forward some points that I came across while working with DBI:

1) Memory management in DBI should be rethought of. The DBI layer should 
be lenient as to its usage by client apps, which means that calls like 
Statement.finish or Database.disconnect should always do their thing 
(free C buffers, close log files, turn off the coffee machine etc.) 
regardless of their being called by the user script or not. For 
instance, the following hypothetical script leaks like hell:

    while [some boolean]
        st = db.prepare([some sql])
        st.execute([some values])
    end

Yes, I know this is not the 'proper' way to use DBI (suppose I never 
heard of 'Database.do'). But DBI should at least it should try to invoke 
"st.finish unless st.finished?" in a finalizer closure if a statement 
object is finalized without having freed its internal resources. The 
same applies to database connections and other environment handles. I 
don't know if the use of finalizers is the correct way to address the 
problem, so I expect your thoughts on this.

2) Parameters returning values: Since some people (including myself) 
will try to use Ruby-DBI with existing systems using stored procedures 
at some point in time, there is very few support in DBI about returned 
values from procedure calls. The problem is difficult to solve taking 
into consideration that Ruby values created as results from stored proc 
calls are not materialised until execution time, so bind_params is not 
the place to do it. Actually, parameter binding should be two-phased 
(before and after execution) so that parameters are bound to and from 
the database,  respectively.

What do you think?

Elias

[Ruby-DBI-devel] Patch: argument to set busy timeout in dbd_sqlite

[Henry H. <haj...@ho...>]

The attached patch against ext/dbd_sqlite/SQLite.c in the current stable
release adds support for an sqlite_busy_timeout argument to the SQLite
driver. If the user does not set, it defaults to 0, which is to return
immediately with an error if the database is busy. This matches the current
behavior.

-- 
Henry House
The attached file is a digital signature. See <http://romana.hajhouse.org/pgp>
for information.  My OpenPGP key: <http://romana.hajhouse.org/hajhouse.asc>.

[Ruby-DBI-devel] Mysql fetch_scroll(PRIOR)

[Bill B. <bil...@ap...>]

Hi,
I discovered that the Mysql::Statement::fetch_scroll(SQL_FETCH_PRIOR) does not fetch the prior row, but the current row. It seems to be easily fixed by decrementing @current_row  like this:

...
  def fetch_scroll(direction, offset)
      case direction
      when SQL_FETCH_NEXT
        @current_row += 1
        fill_array(@res_handle.fetch_row)
      when SQL_FETCH_PRIOR
+       @current_row -= 1
        @res_handle.data_seek(@current_row - 1)
        fill_array(@res_handle.fetch_row)
      when SQL_FETCH_FIRST
...


Of course there may be some gotcha that I dont know about, since i am three days new to ruby.
Ruby seems like a real nice language, I think I am going to like it.
Thanks to all you guys for making the DBI work.

Bill

[Ruby-DBI-devel] Retrieving the final sql statement from DBI::StatementHandle

[James F.H. <jf...@ci...>]

In the process of inserting thousands of records, I occasionally will
get an error thrown. Unfortunately, especially in the case of parse
errors (such as the ones I got when my backslashed weren't properly
escaped), I have no idea what query is causing the problem (I'm parsing
a large file and gathering up bits of data at a time, so I can't 
conveniently go to the offending record).

The attached patches add the capability to see the final SQL statment
sent to the database server for the DBI module in general and the 
DBD::Pg driver specifically.

e.g:

    dbh.prepare(UNCANCELLED_LISTING_QUERY) { |sth|
        sth.execute("jfh", current_month_begin_time)
        p sth.boundsql
    }

----------------------------------------------------------------------
| Jim Hranicky, Senior SysAdmin                   UF/CISE Department |
| E314D CSE Building                            Phone (352) 392-1499 |
| jf...@ci...                      http://www.cise.ufl.edu/~jfh |
----------------------------------------------------------------------

"Given a choice between a complex, difficult-to-understand, disconcerting
 explanation and a simplistic, comforting one, many prefer simplistic
 comfort if it's remotely plausible, especially if it involves blaming
 someone else for their problems."
                                                -- Bob Lewis, _Infoworld_

Re: [Ruby-DBI-devel] Bug in string handling for DBI?

[James F.H. <jf...@ci...>]

On Tue, 22 Oct 2002 07:06:25 -0400
James F.Hranicky <jf...@ci...> wrote:

> There appears to be a bug in the string handling for either DBI#prepare
> and DBI#execute, or else in the corresponding routines in the Pg driver.
> 
> When attempting to insert a Windows pathname such as 
> 
> 	C:\this\is\a\path
> 
> the backslash and the next char are getting interpolated as an escaped
> character, leading to garbage being inserted into the table.

I think I got it:


*** /local/lib/ruby/site_ruby/1.7/dbi/sql.rb.orig  Tue Oct 22 07:48:10 2002
--- /local/lib/ruby/site_ruby/1.7/dbi/sql.rb       Tue Oct 22 07:46:34 2002
***************
*** 87,92 ****
--- 87,93 ----
        case value
        when String
        value = value.gsub(/'/, "''")   # ' (for ruby-mode)
+       value.gsub!('\\\\', '\\\\\\\\')
        "'#{value}'"
        when NilClass
        "NULL"

This seems to fix the problem. 

Jim

[Ruby-DBI-devel] Bug in string handling for DBI?

[James F.H. <jf...@ci...>]

There appears to be a bug in the string handling for either DBI#prepare
and DBI#execute, or else in the corresponding routines in the Pg driver.

When attempting to insert a Windows pathname such as 

	C:\this\is\a\path

the backslash and the next char are getting interpolated as an escaped
character, leading to garbage being inserted into the table.

I tried using Regexp.escape, but that ends up putting the backslashes
used to escape the characters into the table as well, which I'd like 
to avoid.

Does anyone know if there's a quick fix for this?

----------------------------------------------------------------------
| Jim Hranicky, Senior SysAdmin                   UF/CISE Department |
| E314D CSE Building                            Phone (352) 392-1499 |
| jf...@ci...                      http://www.cise.ufl.edu/~jfh |
----------------------------------------------------------------------

"Given a choice between a complex, difficult-to-understand, disconcerting
 explanation and a simplistic, comforting one, many prefer simplistic
 comfort if it's remotely plausible, especially if it involves blaming
 someone else for their problems."
                                                -- Bob Lewis, _Infoworld_

Re: [Ruby-DBI-devel] Pg instability...

[Sean C. <se...@ch...>]

> > Anyone been seeing this in their error logs?  I foolishly upgraded
> > mod_ruby, postgres (ruby module), PostgreSQL, DBD::Pg, and DBI all at
> > the same time and am now getting the following:
> > 
> > [Thu Oct 10 11:40:20 2002] [error] mod_ruby: error in ruby
> > /usr/local/lib/ruby/site_ruby/1.7/DBD/Pg/Pg.rb:33:in `require': wrong argument type false (expected Module) (TypeError)
> >         from /usr/local/lib/ruby/site_ruby/1.7/DBD/Pg/Pg.rb:33
> >         from /usr/local/lib/ruby/site_ruby/1.7/dbi/dbi.rb:444:in `require'
> >         from /usr/local/lib/ruby/site_ruby/1.7/dbi/dbi.rb:444:in `load_driver'
> >         from /usr/local/lib/ruby/site_ruby/1.7/dbi/dbi.rb:384:in `_get_full_driver'
> >         from /usr/local/lib/ruby/site_ruby/1.7/dbi/dbi.rb:364:in `connect'
> 
> As line 33 contains "require 'postgres'" the problem is either in
> postgres (ruby module) or PostgreSQL, but not DBI or DBD::Pg.
> 
> Try
> 
>   % ruby -r postgres -e ""
> 
> Don't think that there's a problem with PostgreSQL.

Agreed.  This list at the moment has the largest agregate set of DB
users on it though so I thought I'd try my luck here.  I'm importing
the postgres source into rubynet at the moment and plan on tracking
its changes and progress there since it doesn't look like postgres is
under any kind of revision control.  I'll let folks know here when I
figure out the problem.  FWIW, I'm writing unit tests for postgres
that'll run under rubytest.  -sc

-- 
Sean Chittenden

Re: [Ruby-DBI-devel] Pg instability...

[<520...@t-...>]

On Thu, 2002-10-10 at 20:52, Sean Chittenden wrote:
> Anyone been seeing this in their error logs?  I foolishly upgraded
> mod_ruby, postgres (ruby module), PostgreSQL, DBD::Pg, and DBI all at
> the same time and am now getting the following:
> 
> [Thu Oct 10 11:40:20 2002] [error] mod_ruby: error in ruby
> /usr/local/lib/ruby/site_ruby/1.7/DBD/Pg/Pg.rb:33:in `require': wrong argument type false (expected Module) (TypeError)
>         from /usr/local/lib/ruby/site_ruby/1.7/DBD/Pg/Pg.rb:33
>         from /usr/local/lib/ruby/site_ruby/1.7/dbi/dbi.rb:444:in `require'
>         from /usr/local/lib/ruby/site_ruby/1.7/dbi/dbi.rb:444:in `load_driver'
>         from /usr/local/lib/ruby/site_ruby/1.7/dbi/dbi.rb:384:in `_get_full_driver'
>         from /usr/local/lib/ruby/site_ruby/1.7/dbi/dbi.rb:364:in `connect'

As line 33 contains "require 'postgres'" the problem is either in
postgres (ruby module) or PostgreSQL, but not DBI or DBD::Pg.

Try

  % ruby -r postgres -e ""

Don't think that there's a problem with PostgreSQL.

Regards,

  Michael

[Ruby-DBI-devel] Pg instability...

[Sean C. <se...@ch...>]

Anyone been seeing this in their error logs?  I foolishly upgraded
mod_ruby, postgres (ruby module), PostgreSQL, DBD::Pg, and DBI all at
the same time and am now getting the following:

[Thu Oct 10 11:40:20 2002] [error] mod_ruby: error in ruby
/usr/local/lib/ruby/site_ruby/1.7/DBD/Pg/Pg.rb:33:in `require': wrong argument type false (expected Module) (TypeError)
        from /usr/local/lib/ruby/site_ruby/1.7/DBD/Pg/Pg.rb:33
        from /usr/local/lib/ruby/site_ruby/1.7/dbi/dbi.rb:444:in `require'
        from /usr/local/lib/ruby/site_ruby/1.7/dbi/dbi.rb:444:in `load_driver'
        from /usr/local/lib/ruby/site_ruby/1.7/dbi/dbi.rb:384:in `_get_full_driver'
        from /usr/local/lib/ruby/site_ruby/1.7/dbi/dbi.rb:364:in `connect'

Any ideas?  -sc

-- 
Sean Chittenden

[Ruby-DBI-devel] Patch to fix autocommit for Pg...

[Sean C. <se...@ch...>]

The attached patch fixes the autocommit functionality for Pg.rb.  In
7.2.3 the AUTOCOMMIT tunable was removed and you can only use
BEGIN/ROLLBACK now.  This is a pretty important fix, IMHO as all of my
scripts that use autocommit are failing without it.  After thinking
about this some, I think having the library keep some kind of track as
to whether or not you're in a transaction is a good idea.  A few use
cases:

*) If you're in a transaction and set dbh['AutoCommit'] to true,
 DBD::Pg will issue a BEGIN, all you get is a warning: no harm done.

*) If you're in a transaction and set dbh['AutoCommit'] to false, then
 you've got a problem.  Do you roll back, commit, or, do you issue a
 warning and do nothing?  I'm a fan of the latter, however this can
 only be done if the library is keeping track of the state.

Thoughts?  This patch doesn't address the above concerns, but it does
get things to a usable state again.  -sc


-- 
Sean Chittenden

[Ruby-DBI-devel] patch to Pg.rb

[MoonWolf <moo...@mo...>]

I wrote a patch to 'Pg.rb'.
It uses ruby-postgres-0.7.0-pre2+my quote patch.

[Ruby-DBI-devel] new patch for ruby-postgres

[MoonWolf <moo...@mo...>]

patch for ruby-postgres-0.7.0-pre2

* PGconn.escape_bytea(PQescapeBytea) add

    PGconn.escape_bytea "\0'\\"  # => "\\\\000\\'\\\\\\\\"

* PGconn.quote extend for DBG:Pg

    PGconn.quote nil    # => "NULL"
    PGconn.quote true   # => "'t'"
    PGconn.quote false  # => "'f'"
    PGconn.quote 1      # => "1"
    PGconn.quote 1.5    # => "1.5"
    PGconn.quote ["a", 1, nil, false]
                        # => "'a', 1, NULL, 'f'"

    PGconn.quote(obj) {|value|
      case value
      when DBI::Date, DBI::Time, DBI::Timestamp, ::Date, ::Time
        "'#{value.to_s}'"
      else
        value.to_s
      end
    }

--
MoonWolf <moo...@mo...>

[Ruby-DBI-devel] patch for coercing values in Mysql.rb

[Brad H. <bh...@vp...>]

Hello,

Please consider applying the following patch which adds support for
coercing values in Mysql.rb in a similar fashion to Pg.rb.  I tried to
follow the same logic that Pg.rb used where appropriate.

Thank you,
-Brad

[Ruby-DBI-devel] coercing column values

[Brad H. <bh...@vp...>]

Hello,

I've been working on an abstraction layer which sits on top of ruby-dbi
that tries to hide the differences of MySQL vs. Postgres.  In so doing,
I noticed that the various DBD drivers don't coerce column values
consistently.

For example, mysql does no coercing of column values, but Postgres
coerces integers to Ruby Fixnums, boolean columns to
TrueClass/FalseClass objects, time/datetime to DBI::Time objects, etc.

MySQL has no boolean column type, but the others would map nicely.  Is
this issue just waiting for a patch?

I also noticed that the default values available through
DatabaseHandle#columns are not coerced.  For example, if you select a
boolean column from a postgres table, you get back either TrueClass or
FalseClass objects.  But if you examine the default value in
DatabaseHandle#columns(), you might see a 't', or 'f'.

Thanks,
-Brad

Re: [Ruby-DBI-devel] pg driver quoting

[MoonWolf <moo...@mo...>]

I wrote a patch to ruby-postgres-0.7.0-pre and sent it to Noboru Saitou.
He said that he will work at a weekend.

It adds 'escape' and 'quote' methods to PGconn class.

    PGconn.escape "foo='bar'"  # => "foo=''bar''"
    PGconn.quote  "foo='bar'"  # => "'foo=''bar'''"

--
MoonWolf <moo...@mo...>