On Tue, 3 Jun 2003, Hal E. Fulton wrote:

> >   relation.select(:field0, :field1){|tuple| tuple[:field0, :field1] === [/foo/, /bar/]}
> > i actually have something which does the above using named fields in
> arrays.
> > it's very cool but slower than dirt ;-)
>
> Named fields?
>
> Did you consider a hash (or better a Struct)?

sure, i considered it, but it doesn't work out too well (IMHO) in actual dbms
code.  consider:

  require 'postgres'
  pgconn = PGconn.new
  sql = <<-sql
    select * from very_large_table
  sql
  tuples = pgconn.query sql

  p tuples[0].class # => Array
  p tuples.size     # => 42,000,000

  fields = [:pk, :f0, :f1]

  if time_to_wait()
    tuples.map!{|tuple| {:pk => t[0], :f0 => t[1], :f1 => t[2]} }
  else
    require 'arrayfields' # http://raa.ruby-lang.org/list.rhtml?name=array-fields
    tuples.fields = fields
  end

  tuples.map{|t| p t[:pk, :f0]}


having named fields in general makes for MUCH more readable database code,
plus most api's give you a means to do something like

  ret = pgconn.exec sql
  tuples = ret.result
  tuples.fields = ret.fields
  ret.clear

at least postgresql does ;-)

but, unfortunately, most apis seem to return Arrays!  one noticable exception
is guy's plruby (procedural ruby for postgres) which *does* use hashes.
however, i've heard that Hashes require much more overhead than array's, and
they also do not preserve ordering so in general i prefer Array's for db code.
when i must map into a hash-like structure i use an RBTree so i can at least
define/enforce an ordering...

more than you wanted to know, i'm sure ;-)

-a
--
  ====================================
  | Ara Howard
  | NOAA Forecast Systems Laboratory
  | Information and Technology Services
  | Data Systems Group
  | R/FST 325 Broadway
  | Boulder, CO 80305-3328
  | Email: ara.t.howard / noaa.gov
  | Phone:  303-497-7238
  | Fax:    303-497-7259
  | ~ > ruby -e 'p % ^) .intern'
  ====================================