Initial commit.

* Set up the package directory tree

* Create DESCRIPTION and NAMESPACE file

* madlib.dim.R: start writing dim function for data frames in database,
  also as an example for function overridden

* onAttach.R:
    * set up 2 local variables
        * one for storing connections,
        * the other for storing connection type of each connection
    * create backups for functions that might be overridden by the
      over-ride script, which will be finished later
    * local constant for supported connection R package
    * local conatant for the function names of possible future
      overridden

* onUnload.R: disconnect all connections that have not been closed yet

* overridden-funs.R: function names to be override together with their
  packages

* supported-connections.R: currently supported connection R package,
  namely RODBC and RPostgreSQL

* utility-check_args.R: check the validity of arguments for functions

* utility-db_rpostgresql.R: wrapper for RPostgreSQL, use connection ID
  instead of connection, and manage connections internally,
  automatically
Make the R file names more consistent
Finished the overall structure of the package.

(1) All data.frame methods will be overridden in its subclass named
    data.frame.indb

(2) Creation functions do not override anyone else, for example,
    data.frame.indb, as.data.frame.indb etc

(3) Some free (or non-generic) functions, such as lm, let the user to
    choose whether he/she likes to really override. The prefix "rmad."
    is used on all such functions. And after overridden, lm function
    would have the same ability as rmad.lm

(4) Make the naming convention of R files more consistent. Usually an
    R file contains only one R function together with its auxilary
    functions (utility files can have more than one function). Any R
    file name starts with a one or two word description for the category
    of the function, followed by "-", followed by the main function
    name, which uses "_" for separating words, and then the extension R.

The remaining things are more technical than strategic.
Make names more consistent, and got a better picture of the package

* Start writing functions that deals with all R connection packages

* It is clear now that a second class is needed for any intermediate
  results in the calculations. Because the data set size might be very
  large, and you do not want to load such big data into the intermediate
  calculation steps. So now:

    * Two subclasses of data.frame: named data.frame.indb and
      data.frame.unsynced respectively

    * Only as.data.frame.ind.data.frame.unsynced() can create a table
      in the database that corresponds to the data.frame.unsynced
      object.

    * Some calculations on indb object generate unsynced object.

    * Any calculation that involves an unsynced object returns an
      unsynced object.

    * Define a resync() function to resync any indb objects with the
      database.

    * Machine learning algorithms accept both objects

* utility-db.R has all the internal functions that connect with the
  database. It can automatically dispatch the call to the corresponding
  R connection package.
Make the class hierachy easier to program

The class hierachy is ("data.frame.indb.uncreated", "data.frame.indb",
"data.frame")

Also remember that S3 generic function needs to be created.

At this point, clearly S3 class is not necessary. S4 can do all of
these. Why do I want to stick to S3?

The original idea is that:
(1) The new class must pass is.data.frame() test. But S3 and S4 both
    work.
(2) Some of data.frame's methods can be utilized in the new class. Then
    S3 becomes the only option.
    However, as it turns out that all the methods need to be override,
    and S3 has no privilidge at all.

Now it seems that S4 is actually a better choice.

Perhaps, the better choice is:
(1) Define a union class "data.frame.indb", which has two subclasses
    named "created" and "uncreated" respectively.
(2) Right now, no immediate benefit could be obtained if we define
    "uncreated" to be a subclass of "created".
Completely switched to S4, created help files and tested installation

Also corrected quite a number of bugs after testing with installation:
* where to put local variables and class declarations
* cannot alter slots in dim
* how to create new methods using setGeneric
* dbDriver can only be used as DBI::dbDriver
etc.

Help files still need more work.

More functions are needed
Make the generic functions better

* use standardGeneric("func") in generic function definition

* define print, show methods

* use \" instead of ' for query

* also tested all current functions

* use "." prefix for slots of indb.created
Summarize and reorganize the previous work

Remembering what has been done
Added more db functions
Merge all changes made in the branch of simpler
Create README.md
Started merging the code bases of Hai and Woo
Added basic structures

* Use S4 for class definitions

* Finished Database access layer

* In the database access layer, only the necessary functions are
  implemented

* db.writeTable needs special care because "distributed by" of GPDB
Use better file names
Added manual files, and make the package compilable
Added port in db.connect

Also let distributed.by == "" be the signature for randomly distributed
table in db.writeTable
Minor changes to improve usability
Tested the current db connection functions

* Removed unnecessary argument checks in the internal functions, and
  only keep argument checks for functions that are exposed to the users

* Various minor changes to improve the usability

* Added fetch function

* Corrected various small bugs

* Added .db.str2vec function
Better return values for db.connect and db.disconnect

* db.connect returns connection ID

* db.disconnect returns TRUE/FALSE
Start implementing db.data.frame