Kamil Kukura wrote:
> I would like to first point out that I don't intent to compare here
> databases like relational vs. object ones. It's all about getting squeak
> and ubiquitous world of relational databases together.

IMHO, Squeak is already well connected to the relational world.
It seems to me that you're looking for a portability layer
(other than ODBC). Or, maybe you're looking for a web-based
CRUD (i.e. Create, Read, Update, Delete) framework.

> When trying to attract web developers from environments such as PHP, ASP
> or JSP, I'm badly missing a thing to show as how Squeak deals with
> external databases. [...stuff deleted]

I don't get what's missing. You can issue SQL, and access the
result set. Then with Seaside, you can spit out HTML.
Can you explain some more about what you expect.

> So I'm thinking what would be nice to have to show up with more
> databases Squeak can natively talk to. Right now I consider to do some
> work on "SqDBC". At first, it would be a package containing ODBC and
> ODBCEnh as its default database driver.

Why is an SqDBC layer needed? If the reason is rdb portability,
doesn't ODBC already give you that. IME, you end up building a
framework (or use code generation) to access the database anyway;
so why shouldn't that framework target the database driver directly,
instead of an intermediate layer.

>  Then I would like to "grow up"
> PostgreSQL package in the way it would become SqDBC driver (and upgrade
> it to protocol 3 as well).

There happen to be three PostgreSQL drivers. Apart from
connection pooling and authentication support, the driver that
I wrote was never intended to be much more than it already is.
It simply sends SQL, and returns a result set. It was expected
that some kind of object mapping, code-generation, CRUD package
would be built on top. (In fact, I'm working on such a thing).

As for protocol version 3, I looked at it earlier and figured
it was not worth doing, just to get:
    - perhaps better error recovery
    - prepared stmt support
If there's interest, I can look at implementing it.

> Then add some connection pooling to SqDBC.

Connection pooling would be good. (There's pgpool for PostgreSQL,
but it wouldn't be a native Squeak implementation.)

> I know it looks quite "javish" as their JDBC but I don't know if is
> there better "natural" approach.

I think JDBC is just ODBC protocol written in Java, so it
adds nothing to what ODBC provides.

--yanni