On Thu, Mar 29, 2001 at 05:16:54PM -0500, Andrew Hammond wrote:
> independant way of accessing metadata. Writing SQL queries that derive
> metadata by futzing around with the pg_* tables works but is totally
> non-portable. What I would really like to see is a database interface
> layer that encapsulates all that nasty mess. Metadata and other
> introspective stuff is a glaring ommission from SQL.
I have written something that does this in two directions: listing out the
indices, tables, columns, etc. For a simpleminded db abstraction layer for
work. I can provide code shortly.
IMHO the database "abstraction toolkits" are all missing the point. In my
scripts, I want my variables. Now. It failed? Not the concern of the
script.
So far I've laid out 5 functions:
# returns the value of that column or NULL if it's NULL
$scalar = db_value("SELECT column FROM table WHERE unique_id=5"):
# returns an array of values of these columns
$list = db_list("SELECT column FROM table");
# returns a hash[column] = value
$row = db_row("SELECT * FROM table WHERE unique_id=5");
# returns a array of hashes
$rows = db_row("SELECT * FROM table");
# for sending updates, etc.
$result = db_send("UPDATE/INSERT/DELETE whatever");
All the guts of connections, interation, freeing results, etc. are hidden.
I've even implemented failover behind the scenes.
Error handling is ambiguous with respect to NULL values, so that gets a -1
until something exception-like appears in the language. (And I'm not in a
hurry for that.)
This has turned out to be really effective.
One thing which would also be amazing (also borrowed from some simple-DBI
thing) is to automatically map primary keys into hashes. So when fetching a
bunch of rows that have a primary key:
$rows = db_row("SELECT pkey, value FORM table", 'user_id');
# $rows['somepkey'] is then a reference to the value of that key
Get it?
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org